Presentation service which enables client device to run a network based application

ABSTRACT

A presentation server which enables a client device to run a network based application by sending structured data from one or more data sources to software on the client device. The presentation server decouples the client device from the data source by (i) insulating the data source from needing to handle directly any display, data storage, data querying or communications functions relating to the client device and (ii) insulating the client device from needing to handle communications functions which are specific to the data source.

BACKGROUND TO THE INVENTION

[0001] 1. Field of the Invention

[0002] This invention relates to a presentation server which enables aclient device to run a network based application client softwareenabling a client to run a network based application. It findsparticular utility in enterprise computing. A ‘presentation server’ isgenerally any kind of server that determines how data will be displayedon a client device.

[0003] 2. Description of the Prior Art

[0004] Enterprise computing was originally conducted through largemainframe computers. These mainframes gave the end-user very limitedapplication functionality, displaying only text messages and requiringkeyboard strokes for every command (for example, there was no mouse andnone of the richness of today's desktop applications like drag and drop,graphing, sorting or personalized settings). Deployment costs were alsovery high due to the cost of hardware and the lack of skilled computeroperators.

[0005] The evolution to client/server-based computing provided muchricher functionality. The graphical user interface (GUI) providedend-users a much simpler, more efficient method to interact withapplications, but systems still proved expensive and difficult tomaintain. In theory, applications would be deployed on the servercentrally and distributed via the network to each of the clients. Butbusiness users had different needs of functionality and thereforerequired different applications with unique configurations. Not only didsome information have to be personalized, but information also had to beretained on the desktop.

[0006] This meant it was not possible to “write once and deploy many”.The result was that the end-user got the desired rich functionality, butmuch of the code for the business logic for the applications was locatedon individual clients. IT Departments' budgets ballooned due to highsupport costs and slow implementation times. Rolling out newapplications—or even minor updates—required a unique installation forevery PC that required access.

[0007] The advent of the Internet was supposed to change all this. TheInternet provided an infrastructure that lent itself to the notion ofzero-cost deployment with the promise of “write once, run anywhere”.Such a model would significantly decrease the cost of deployingenterprise systems. With the Internet, back-end servers would run theapplication centrally, and all that users required to access theapplication was a browser. There would be no code specific to theapplication running on the user's client. The potential this promised tolarge companies was unprecedented.

[0008] Despite the enormous potential, the initial technology (HTML)used for building and deploying the front-end of these new Internetapplications was never intended for anything more than displaying simpletext. As companies tried to deploy sophisticated business systems overthe Internet, they soon realized that much of the desired functionalitythey wanted was not feasible. HTML based Web Applications did not havetrue interactivity or access to data in real-time. Business users neededto interact with and manipulate the data, but mostly what they saw wasstatic page views. Certain solutions were designed to provide a moreinteractive user interface. However, they still used variations of HTML,resulting in passive documents with numerous limitations.

[0009] Specifically, from a technical perspective these limitationsresulted in:

[0010] Lack of functionality: No matter how sophisticated the back-endbusiness logic, end-users lost the functionality they had come to expectfrom their familiar client/server-based system. Large online systemsthat were deployed severely lacked the rich functionality that companiesdemanded in their offline systems. While lots of money was spent onbuilding these systems, to date they have dearly not replacedclient/server systems. In fact, very few even augment the existingoffline systems, and in retrospect proved to be very expensive ITexercises which fell short of their original promise. There have beenearly attempts at providing a richer user interface and a more robustconnection between the back-end servers and the client by usingJavaScript, DHTML, and various plug-ins. However, these solutionspresent expensive development cycles and ongoing maintenance, whileintroducing new security issues (see below), and applications that stillfall short of the desired functionality.

[0011] Load on back-end Servers: The HTML-based Web represents a veryinefficient use of computing resources. Publishing HTML's required pageby page structure means that as more people log on to a system, requeststo the database and the application server put a strain on theseservers. Companies needing to scale operations can buy more servers withmore CPUs to handle the high load, but each additional processor notonly costs a lot, but may also affect the license cost of all thevarious software packages running on the server.

[0012] Security Concerns: Companies are concerned that data pushedbeyond corporate firewalls onto the Internet is open to unauthorized,third-party scrutiny. Additionally, there is concern that plug-insdownloaded from various Internet applications may contain viruses. Mostsoftware companies license their software on a per-CPU basis. Ascompanies add more CPUs to their servers or add entirely new servers,the licensing fee for each piece of software increases by a multiple ofhow many new processors are added.

[0013] Cannot Easily Prototype New Features: Given the complexity ofdeveloping user interfaces that provide adequate functionality and theeffort required to integrate such solutions to the back-end, companiestypically do not prototype and roll out new features incrementally. Veryoften, further development of these systems is an extensive project,which introduces the uncertainty of never being fully deployed and used.Because of the effort required for each release, many companies shy awayentirely from going forward on certain projects as opposed to rapidlydeveloping incremental pieces to see what parts work.

[0014] From a business manager's perspective, these limitations meant:

[0015] Inadequate Systems for Doing Business: Client/server-basedsystems were expensive, difficult to build and deploy and not accessibleoutside of the enterprise. However, they do provide the functionalityneeded to actually do business, whether for trading financialinstruments, managing resources and accounts through ERP systems orselling and maintaining client relationships through SFA and CRM tools.A fraction of these capabilities are available over the Internet incertain systems, but are far from giving the functionality peoplerequire to be effective.

[0016] Slow Performance: Sites using HTML force users to click and waitfor a response while the back-end system processes the information andpushes a new page to the users. This can take a few seconds at best, ortens of seconds, even minutes, at worst. Users of these systems simplyabandon activities when they take too long or when connections entirelyfail.

[0017] Expensive Development: Building and deploying enterprise-levelsystems over the Internet with sophisticated functionality requires alot of custom coding with long and expensive development cycles. Most ofthis work cannot be leveraged for other systems and is a large, one-offexpense that companies must absorb.

[0018] Expensive Maintenance: Complex Web systems contain thousands oflines of code on both the back-end (business logic) and the front-end(delivers the interface). The connection between the front-end andbackend also contains thousands of lines of custom code which needs tobe debugged and maintained. All changes to the code require programmersto manually write new code and test the functionality through stagingbefore going to a live production site.

[0019] Expensive Bandwidth: In today's online systems, information ispresented to users through entire Web pages, which are pushed out tousers over the network. As information changes or transactions arecompleted, users can request new pages or submit pages back to thesystem. However, every time pages are sent across the network, companiespay for the bandwidth used. As online systems add users and these usersstart to do more activities online, they consume more and morebandwidth, and as a result costs increase quickly.

[0020] Mobile Access: As the reach of the Internet extends beyond thePC, enabling mobile access (i.e. PDAs, Cellular Phones) to businessapplications is becoming a standard business requirement. Currentsolutions for wireless delivery require separate application re-writes(and expertise) for each device supported.

[0021] Hiring and Retraining expensive IT Staff: Integration of Websystems with existing offline systems and the maintenance of moresophisticated user interfaces for the Web using JavaScript and HTMLtypically requires armies of programmers, burdening the budget of everydepartment, and many times putting the overall company's viability injeopardy.

[0022] As a result of these challenges experienced to date, companiesstill have limited confidence in deploying their systems through theWeb. Re-creating the same feature-rich interfaces that existed onclient/server-based desktop applications has proven futile for companiesattempting to move their systems to the Internet Replicating theperformance of desktop applications as well as standardizing thecollaboration and interaction between disparate Web applications hasbeen even more complex, expensive, and mostly elusive. The massivetrade-off in end-user productivity, combined with security, scalabilityand performance concerns, has resulted in enterprises runningclient/server systems in parallel with Web-enabled systems, furtherdeepening the cost of IT, and still not realizing most of the benefitsthe Internet promised.

[0023] Hence, even though millions of people are now using the Internetto look at documents from anywhere in the world, true interactivity tomanipulate data is missing, and the evolution of the Web into amainstream business and trading environment simply has not happened.

SUMMARY OF THE PRESENT INVENTION

[0024] In a first aspect of the invention, there is a presentationserver which enables a client device to run a network based applicationby sending structured data from one or more data sources to software onthe client device, wherein the presentation server decouples the clientdevice from the data source by (i) insulating the data source fromneeding to handle directly any display, data storage, data querying orcommunications functions relating to the client device and (ii)insulating the client device from needing to handle communicationsfunctions which are specific to the data source.

[0025] Because the present invention relates principally to a clientserver architecture, it may be helpful to describe the entireclient/server architecture at this point so that the presentation server(‘Presentation Server’) can be seen in context. This client serverarchitecture envisages a new approach which is neither entirely thickclient, nor entirely client-server, nor entirely fully distributed, butblends aspects of each. (The Presentation Server could in principle alsobe implemented in a peer to peer architecture, or in an entirely closeddevice, but the client server architecture is currently seen as the mostcommercially significant).

[0026] The Presentation Server receives structured data (or super-setsof it) over a network from an originating data source, which may be aweb server, a back end application, a messages queue or a web service(or multiple sources of these types) able to generate structured data,such as XML or SQL format data directly (or indirectly through agenerator). It then intelligently passes that data onto client deviceswhich require it. The client in one implementation is a unique threelayer client, in which the three layers are:

[0027] (a) a communications layer to send and receive messages over thenetwork;

[0028] (b) a database layer to store, and allow querying of, thestructured data;

[0029] (c) a rendering layer which generates, from the structured datain the database layer, data for a user interface;

[0030] such that the client software is self-contained to provide all ofthe communications, data storage and rendering resources needed to runthe network based application on the client device.

[0031] The Presentation Server subsequently keeps the database layer inthe ‘3 Layer System’ automatically updated (or ‘synchronised’) with theoriginating data source. The Presentation Server insulates theoriginating source from needing to know which clients need to beupdated, what updates they need, how to communicate with clients, andthe user interface at the clients. This overhead is instead handled bythe Presentation Server; this approach allows a networked applicationdeveloper to concentrate on application business logic development,rather than the front-end display/communications and synchronisationelements that traditionally take over 50% of developers' time. Strictlyseparating the data source from the client device allows the businesslogic of an application to be fully independent of the presentationlogic on the client device, such that the data source need not even knowof the existence of a client device even though it may be a necessarypart of the network application. Similarly, it allows the presentationlogic of a client device to be fully independent of the business logicon the data source, even to the extent that the client device need noteven know of the existence of a data source even though it may be anecessary part of the network application.

[0032] By pre-fabricating these complex functions and capabilities intoa generic Presentation Server, networked application developers canproduce finished applications far more quickly than previously. Scalingto large numbers of clients (10000s) is also possible, even for legacyback end systems which are limited to serving 10 or fewer clients. Thisis because the back end system needs to supply information just once tothe Presentation Server, the Presentation Server itself is fullyscalable (e.g. multiple CPUs; multiple CPUs on multiple machines etc.)to serve the required numbers of client devices.

[0033] Communication between the Presentation Server and the data sourcecan be carried out locally or over a network and interaction can occur:

[0034] via services provided by the data source (e.g. HTTP & CGI; SOAP);

[0035] via message queues to which the data source publishes and thePresentation Server subscribes;

[0036] via message queues to which the Presentation Server publishes andthe data source subscribes;

[0037] via direct calls to the data source's application programmableinterface (API) where the underlying system provides the low-levelprotocol (e.g. Remote procedure calls; CORBA);

[0038] via direct calls to one or more databases on the data source;

[0039] in a loosely coupled way (e.g. via e-mail or ftp file transfer).

[0040] The Presentation Server can be thought of as allowing the datasource to configure or handle indirectly any display, data storage, dataquerying or communications functions relating to the client device byforwarding communications from the data source to client software on theclient device. The data source only indirectly configures the clientdevice because it is the Presentation Server which:

[0041] manages updates of the structured data held on the client deviceby regularly polling the data source for changes;

[0042] directly manages distribution of streaming data to multipleclient devices, where the data source needs only to provide a singlestream to a Presentation Server which in turn broadcasts the informationin a scalable fashion to multiple (potentially more than tens ofthousands) of client devices that may in turn be connected to thePresentation Server at different performance rates over the network;

[0043] handles communications functions specific to different clientdevices by having a generic communications capability (datareceipt/acknowledgement/response) enabling it to communicate withmultiple client browsers, multiple client device types and acrossmultiple bearers; or

[0044] handles communications functions specific to different clientdevices by having a generic display capability by being able to downloadto the database layer one or more of the following, each configuredappropriately for a destination display, device type and bearer: such aspanels, windows, controls, data binding to the controls and eventmodels.

[0045] Additionally, the Presentation Server can insulate the clientdevice from:

[0046] needing to directly handle communications functions which arespecific to the data source, by translating messages from the clientdevice to a form suitable for the data source;

[0047] needing to directly interpret raw data provided by the datasource, by translating messages from the data source to a form suitablefor the client device;

[0048] needing to directly manage updates of the structured data held onthe client device, by receiving a single data update from the datasource and being solely responsible for identifying all client devicesthat need that data update, and sending the appropriate updating data toall of the client devices that need it;

[0049] needing to know the quantity or configuration of multiple datasources to which the Presentation Server is connected, by aggregatingdata from multiple data sources into a single data stream for eachclient device.

[0050] Further key features of implementations of the PresentationServer are defined in the claims. Implementations of the inventioninclude a Presentation Server which:

[0051] maintains a data stream per client device in which the data ispushed over a persistent connection to the client device over thenetwork as soon as it is available;

[0052] maintains a data stream per client device in which the data issent to the client device over the network in response to regular orad-hoc polling requests from the client device;

[0053] compresses the data received from the data source prior tosending the information to the client device;

[0054] encrypts the data received from the data source prior to sendingthe information to the client device, thus insulating the data sourcefrom the enhanced security needed to allow a remote client device to runthe network application over a public or insecure network;

[0055] decrypts the data received from the client device prior tosending the information to the data source, thus insulating the datasource from the enhanced security needed to allow a remote client deviceto run the network application over a public or insecure network;

[0056] can process a request by the client device for an update to adata source and return an indication of whether the update wassuccessful as indicated by a response from the data source; if theupdate fails, the data source may optionally provide further informationabout the reasons for the failure in a way that can be displayed orinterpreted by the client device (e.g. in an equity trading application,the data source might indicate that the quantity of a stock to bepurchased exceeds some limit imposed by business rules and can notifythe Presentation Server of the problem who in turn can forward theinformation to the client device);

[0057] can process a request by the client device for an update to adata source and return an indication of whether the update wassuccessful even if the data source does not directly respond with asuccess or failure indication (e.g. where no response for a periodimplies a failure to update the data source); it may be configured toautomatically generate responses to the client device on behalf of thedata source;

[0058] can process a request by the client device for a singletransaction update to multiple data sources and return an indication ofwhether the update was successful;

[0059] can process a request by the client device for a singletransaction update to multiple data sources in such a way that all datasource updates are only confirmed once each data source haspreliminarily indicated that the update would succeed;

[0060] provides that failure of any one of the transaction updatescauses all the transaction updates to be cancelled and a failureresponse to be returned to the client device that requested thetransaction;

[0061] provides that a preliminary validation of all transactions causesall transactions to be confirmed and returns a success indication to theclient device that requested the transaction;

[0062] returns the message that results in the user interface at theclient device being updated at the same time as it issues a message thatresults in the user interface of different client devices being updatedin the same manner;

[0063] can update marginal portions of the database layer in a clientdevice by sending, instead of an entire structured data tree hierarchy,a key which identifies the part of the structured data tree which haschanged;

[0064] can update a database layer by altering, in real time,configuration data held in the database layer which defines how thestructured data can be interacted with from within the user interface;

[0065] can prioritise updates to a client device that is returningon-line after an absence;

[0066] can update the database layer by re-initialising all of thestructured data on a client device that is returning on-line after anabsence by applying rules to determine if re-initialisation isappropriate;

[0067] stores updated structured data in a transaction log record fromwhich a client can pull updates;

[0068] stores updated data in a transaction log record and pushesupdates as appropriate to the client device;

[0069] is able to send updating data to different client devices atdifferent times or frequencies;

[0070] can be configured to skip unnecessary intermediate updates tostreaming data for devices whose connection or client device is tooinefficient to receive and process every update (e.g. an equity quoteapplication might update 10 times a second, but a certain device mightnot accept more than an update every 5 seconds. In this case, thePresentation Server would effectively send only every 50^(th) update tothat client device, whilst it might simultaneously send all 50 updatesto another more efficient client device);

[0071] can maintain a statefull connection with the client device, e.g.by routing a unique, incrementing number to the client device, which thePresentation Server logs in relation to all data updates, so that whenthe client device returns on-line from an absence, the client devicesends the latest number it received back to the Presentation Server sothat the Presentation Server can determine what updates the clientdevice did not receive and therefore need to be sent;

[0072] is sent by the client device any parameters that need to bepersistent and stores these parameters or routes them to storage forlater retrieval;

[0073] provides scalability in the number of client devices a networkbased application can communicate with by being itself scalable with:

[0074] (a) multiple CPUs on a machine;

[0075] (b) multiple CPUs on multiple machines in a parallel or in aparent/child arrangement;

[0076]  and manages the message flows from each CPU to the applicableclient devices;

[0077] provides fault tolerance by being itself scalable with:

[0078] (a) multiple CPUs on a machine;

[0079] (b) multiple CPUs on multiple machines in a parallel or in aparent/child arrangement, providing a mechanism to automaticallycompensate for failures of instances on one or more CPUs byreconfiguring the network configuration at run-time and optionallyre-establishing connectivity for each orphaned client device to analternate Presentation Server;

[0080] can form part of a network of several geographically separatedPresentation Servers, some or all of which operate as edge servers;

[0081] can form part of a network of several geographically separatedmachines organised into a topology which is appropriate to the physicalarrangement of sites in a business running the network basedapplication;

[0082] can combine structured data from several different server basedapplications for a given client device;

[0083] can determine automatically and in real time, when a clientdevice requests several images, whether it should reduce bandwidthconsumption by placing all of the images into a single, composite imagefile, each image sharing data which is not image specific;

[0084] modifies the data it sends to a client in dependence oninformation sent to it from the client which relates to the displaylimitations of the client device.

[0085] uses a session object associated with an applet to determine thespecific display parameters and structured data to be served to theclient device.

[0086] Other aspects of the invention include:

[0087] A web application which, when invoked or run, causes aPresentation Server as defined above to be run;

[0088] A hardware server which hosts a Presentation Server as definedabove.

BRIEF DESCRIPTION OF THE DRAWINGS

[0089] The present invention will be described with reference to theaccompanying drawings, in which:

[0090]FIG. 1 is a schematic of the main components of the AltioLiveClient (ALC);

[0091]FIG. 2 is a schematic showing the order of events, which occurwhen a client communication is initiated;

[0092]FIG. 3 is a schematic showing the chain of events, which occurwhen a user does something, which requires additional data;

[0093]FIG. 4 is a schematic of various aspects of the ALC configuration;

[0094]FIG. 5 is a schematic of a simple Synchronization Engineconfiguration;

[0095]FIG. 6 is a schematic of a complex Synchronization Engineconfiguration;

[0096]FIG. 7 is a schematic of the AltioLive Deployment Architecture;

[0097]FIG. 8 is a representation of a screen view. The initial dataserved by the Synchronization Engine is shown in this example;

[0098]FIG. 9 is a representation of a Service Function;

[0099]FIG. 10 is a representation of a screen view depicting theDatapool;

[0100]FIG. 11 is a representation of a screen view of a “NEW_SALE”Service Function;

[0101]FIG. 12 is a representation of a screen view of a “NEW_BID”Service Function;

[0102]FIG. 13 is a representation of a “Select Produce” list, includinga GET_APPIMG image server command;

[0103]FIG. 14 is a schematic of the full system architecture of anAltioLive application;

[0104]FIG. 15 is a schematic of the interaction between theSynchronization Engine and the Application with emphasis on three mainareas; the Data Service Function, Image Service Functions and Datapools;

[0105]FIG. 16 is a schematic of AltioLive in Dynamic Mode. In Dynamicmode it is necessary to change the HTML to reflect the connection to theSynchronization Engine;

[0106]FIG. 17 is a schematic of the Logon process used by the AltioLiveDemonstration applications.

DETAILED DESCRIPTION OF THE PREFERRED IMPLEMENTATION

[0107] The invention will be described with reference to animplementation called AltioLive, from Altio Inc. of Boston, Mass., USA.This Detailed Description is organized as follows:

[0108] A. AltioLive—a Brief Overview of the Overall Architecture

[0109] B. AltioLive Client—Overview

[0110] C. AltioLive Presentation Server —Overview

[0111] D. AltioLive Client—Details

[0112] E. AltioLive Synchronisation Engine (SE)—Details

[0113] F. Deploying AltioLive

[0114] G. Security Aspects of AltioLive

[0115] H. AltioLive—Benefits of using AltioLive

[0116] I. Glossary

[0117] Appendix I “Getting Started with AltioLive” from Altio Inc.;Chapter 3 titled ‘The AltioLive Presentation Server’

[0118] Appendix II “Integrating AltioLive” from Altio Limited; Volume 4Chapters 1-5 of the AltioLive User Documentation.

[0119] A. AltioLive—a Brief Overview of the Overall Architecture

[0120] AltioLive solves the technical challenges of streamliningdevelopment, deployment and maintenance of real-time interactiveInternet/web applications. Updates to data items are received ‘live’ ata client device and can be transmitted concurrently and automatically toclient devices to avoid users requesting updates and then having to waitfor server responses. Access to the application through alternatedevices (e.g. wireless access) presents the user with their dataautomatically rendered for display and navigation on the device, whetherit is a cell phone or a Personal Digital Assistant (PDA). For certainPDAs, AltioLive can be implemented directly (e.g. IPAQ). For cellphones, Web TV and lightweight PDAs, the application is provided viaHTML or WML pages generated by a renderer engine in the PresentationServer. Thick client functionality is not provided on these devices.

[0121] Applications developed with AltioLive provide users the abilityto move between windows inside the browser, scroll or sort throughlists, resize columns and see details on selected items (includingcharts and graphs). The windows can be minimized, maximized, movedaround and resized, just like in a standard desktop application.Customizable toolbar buttons allow the user to pop-up additional windowsto view further details such as lists, forms or graphs. Data entry isprovided through the typical controls such as text boxes, checkbox,drop-down lists etc. with additional complex controls such as graphs,tree-views, date and color pickers.

[0122] Since developing applications with AltioLive requires virtuallyno coding, development and ongoing maintenance efforts are reduced up to75% while bandwidth and server-side processing decrease by a similarorder of magnitude.

[0123] In AltioLive, an Altio Presentation Server (‘APS’) deploys andintelligently manages real-time, interactive Internet or Webapplications by serving appropriate XML data to client devices. Thefunctions of the APS are (a) to receive and store XML data from thesource of that data (e.g. web server, web service provider etc.); (b) tosupply to each client device an appropriately configured 3 LayerSystem—in this instance a generic applet (as described above)—thisgeneric applet handles client device display and communicationsfunctions; (c) configuration, initial data and supporting files imagesand ‘skins’) and (d) to provide XML formatted data updates to the clientin real-time and (e) to process client device requests to processupdates and/or provide further information.

[0124] The APS therefore assumes responsibility for properly configuringthe generic applet so that the database layer (an XML database layer inthe case of AltioLive) on the client displays the correct data for aparticular user, in the correct format and with window controlsappropriate to that user, and in an optimal manner for the displaycapabilities of different client devices. It also assumes responsibilityfor all communications functions to/from the client device byappropriately configuring the generic applet, which it sends to theclient device. The communications functions enable data to be exchangedwith any device type and OS (e.g. PC, Apple™, Unix™, Symbian™, Palm™etc) and over any bearer/protocol.

[0125] The updating function ensures that all client devices are up todate or synchronized. In AltioLive, this function is achieved using oneor more clustered ‘Synchronization Engines’ (SE). A SE is a server-sidesoftware application, which runs on the Altio Presentation Server, andcoordinates and controls the interaction between multiple clients, Webapplications and server data sources over multiple communicationprotocol types, while still being configurable via industry standard XMLThe SE allows for enterprise scale real-time data updates without theneed for a client to use a browser ‘refresh’ button; live datasynchronization across multiple users is possible. Static applicationscan therefore be transformed into dynamic ones and these applicationscan be extended to multiple devices in different formats, all from acentrally managed location.

[0126] In AltioLive, the generic applet is called the AltioLive Client;this applet enables live data to be displayed in fully interactivewindows inside a user's browser. Upon a request to the web server orother ultimate data source, by the client device, the AltioLive Clientis deployed to the user's machine from the SE as a small Java applet.The applet is generic and self-contained—i.e. no additional code isneeded to make it suitable for a specific purpose. Instead, itinterprets the configuration file sent from the SE to implementdifferent views and behaviours so that it works for a specific webapplication/client device/bearer combination.

[0127] B. AltioLive Client—Overview

[0128] The AltioLive client has three layers:

[0129] (a) a generic communications functions layer (establishing andmaintaining connections; re-connecting; updating etc.);

[0130] (b) a generic rendering/graphics layer (generates appropriatescreen responses to mouse drags and actions etc.) and

[0131] (c) a database layer (stores applet configuration parameters andUI parameters like windows, window controls, data binding to thesecontrols and event models; stores also the web application related data(a super-set of what is displayed at any time)).

[0132] All three layers are necessary parts of the 3 Layer System, andeach plays an important role in delivering the desiredfunctionality/behavior.

[0133] B.1. The Communications Layer

[0134] The communications layer provides a means to robustly send andreceive messages between the network based application running on theclient, and the necessary supporting Presentation Server.

[0135] Key Features:

[0136] Establish connection with Presentation Server to obtain interfaceconfiguration information (in a current implementation this is deliveredas XML)

[0137] Establish occasional on-demand connection with the PresentationServer to obtain ad-hoc information as needed by the network basedapplication (e.g. a response to a search query)

[0138] Establish occasional on-demand connection with the PresentationServer to deliver new and/or updated network based application data tothe Presentation Server (e.g. when a user submits a form), and await aresponse on success/failure

[0139] Establish regular polling connections to receive network basedapplication data to be presented in the interface

[0140] Establish and maintain a persistent connection to a PresentationServer if required for low-latency receipt of streaming data

[0141] Establish occasional connections with the Presentation Server toensure server is alive (functioning) if needed when no streaming datahas been received for a significant period.

[0142] Interface to the Database Layer to deliver new and updatedinformation from the Presentation Server

[0143] Interface with Database Layer to receive messages to be sent tothe Presentation Server (e.g. when the network based application data ischanged)

[0144] B.2 The Database Layer

[0145] The Database Layer provides a means to hold and query networkbased application data and user interface configuration data as well asan interface to the Communications Layer and the Rendering Layer.

[0146] Key Features:

[0147] In the generic case it receives digital information from thecommunications layer and efficiently store it for later access on demand

[0148] Receive structured data from the Communications Layer that maylater be queried using a query language to combine and/or extractspecific subsets of data on demand

[0149] The structured data may be XML; XML querying approaches can beused to combine and/or extract data subsets

[0150] The Database Layer can provide temporary cacheing of networkbased application data on behalf of the rendering layer, in order toreduce and/or minimize the need for the 3 Layer System to communicatewith the server in the course or running the network based application.

[0151] The Database Layer supports dynamic additions, modifications anddeletions to the information it holds, triggered either by theCommunications Layer or the Rendering Layer.

[0152] The Database Layer responds on demand to requests for informationfrom the Rendering Layer.

[0153] The Database Layer may in response to a request from theRendering Layer, issue a request in turn to the Communications Layer toretrieve further information from the Presentation Server (e.g. when theRendering Layer has asked for data not yet present in the DatabaseLayer)

[0154] The Database Layer may have a means to manage its size and maychoose to expire and/or archive old or infrequently accessed information

[0155] The Database Layer works in conjunction with the Rendering Layerto automatically trigger changes to the user interface to reflect thecurrent state of the data in the Database Layer

[0156] B.3 The Rendering Layer

[0157] The Rendering Layer provides a means to (a) combine informationdescribing an interface for a network based application with informationto be rendered within that interface and (b) dynamically construct andmanage the display of the application interface on the host clientplatform (e.g. a web browser or handheld device).

[0158] The Rendering Layer generates a user interface that reflects thestate of the information in the Database Layer

[0159] Subject to the capabilities of the client device, the RenderingLayer can generate a dynamically updated user interface that continuallyreflects the latest state of the information in the Database Layer

[0160] The Rendering Layer may support interaction with an end userthrough inputs from an external input device (e.g. a keyboard, buttonpanel or mouse)

[0161] The Rendering Layer may generate a network based applicationinterface at the pixel level

[0162] The Rendering Layer is responsible for generating and managinguser interface controls (e.g. text entry boxes, charts, scroll-bats)

[0163] The Rendering Layer may display information in a traditionaldesktop format using multiple overlapping views.

[0164] The Rendering Layer may support user interaction with the userinterface such as drag & drop of information between views, enteringdata into a text box, pressing a button.

[0165] The Rendering Layer may support rendering of network basedapplications on devices and/or in a form other than pixels on a screen.(e.g. lines of text on a cell phone or LEDs on a domestic appliance)

[0166] The Rendering Layer may support interfaces to alternativerendering mechanisms independently of its own drawing capabilities (e.g.Javascript calls and triggers to and from the Rendering Layer)

[0167] Other key features of the AltioLive Client are:

[0168] The generic applet provides a generic display capability by beingable to download from the remote Presentation Server one or more of thefollowing, each configured appropriately for the destination browser,device type and bearer: windows, controls on the windows, data bindingto the controls and event models. The XML data is bound to the controlsand event models, so that a web application developer need only definewhat data is to be associated with each window control; the applet thenhandles how data should be displayed when different events occur (e.g.if the data is a list of names, the applet handles how the name list isdisplayed if a ‘sort by alphabetical order’ control is selected). This‘View’ definition can be made specific to each user—allowing differentusers to be able to see or manipulate different data sub-sets and henceproviding an access control mechanism.

[0169] The applet provides a zero-client footprint in that it is (a)installed on a client device only in response to the client deviceinitiating or requesting a web application or web service and thereforedoes not need to be pre-loaded or installed and, (b) after the clientdevice has ceased using the web application or web service, it may beremoved entirely from the client device.

[0170] The small size of the applet allows it to be rapidly downloaded.Once the Java applet is running on the user's machine, it maintains apersistent connection with the Presentation Server. The PresentationServer will then ‘push’ or propagate new data to all parties thatrequire it Only data, which has actually changed, is pushed across thenetwork, reducing the bandwidth used, unlike HTML systems that send anentire page when only a single data point in the page alters. Anotheralternative to the persistent streamed connection is a pollingconnection, which makes regular requests for data changes. This uses atimestamp mechanism to ensure that only new updates for the individualclient making the request are returned.

[0171] The XML database provided by the applet enables XML data from twoor more different web applications, web services or data sources to becombined or manipulated in one or more windows running in a browser onthe client device as though from a single source.

[0172] The generic applet can generate multiple windows in a browserwindow of the client device, with a user able to sort data, edit data,or scroll through data in each of the windows, without the need forthere to be any client side software development

[0173] The generic applet allows XML to be cut and pasted into aclipboard or other form of temporary memory. Hence, a user can drag data(e.g. numerics, text or images) from one window generated by the XMLdatabase and drop it into another window—the appropriate changes(including computations) resulting from pasting in the new data into theapplicable field of the new window are generated and displayed.

[0174] The generic applet can generate multiple windows in a browserwindow of the client device, with each user able to define apersonalised arrangement of windows and data to be displayed in eachwindow, with the data to be displayed in each window capable of beingobtained from several different web applications or web services.

[0175] XML data is associated with pre-defined controls by a developerand then at run time the generic applet automatically displays the datain conjunction with some or all of those controls.

[0176] The XML database can be accessed using XPath queries, in whichstandard XPath queries are enhanced with the following features: indexedretrieval; direct reference to elements and attributes identified bycontrols.

[0177] Session objects can allow the remote Presentation Server toprovide to the XML database the applicable data and configurationparameters appropriate to the client device and the last state of theclient device known to the remote Presentation Server. This preventsunauthorised access without a session object. Session objects are userspecific, so that users can access a web application irrespective ofclient device being used. The PS also maintains the notion of aConnection, allowing a single session to support multiple connections(two browser windows for example) each running a differentview/configuration.

[0178] C. AltioLive Presentation Server (APS)—Overview

[0179] The AltioLive Presentation Server (APS) integrates with WebApplications to efficiently and securely distribute live XML data tousers across the Internet through the range of Altio Clients. The APShas the following three functional aspects:

[0180] Display—The APS provides a trusted architecture for thepresentation of real-time interactive applications. Through a tiny,browser-based applet and XML configuration, Internet applicationsdeliver a completely customisable, dynamic interface with desktop-stylefunctionality (e.g. drag and drop, resizable windows, customisablescreen colours, customisable fonts, fill UI configurability according touser's role and preferences).

[0181] Communications—The connection between the application (on theserver) and the end-user (on the client) governing the form and methodof communication between the application (on the server) and display tothe user (on the client). The APS provides a persistent, secureconnection between the application and clients, transmitting data viaconfigurable HTTP/HTTPS polling or streaming access mechanisms.

[0182] Data Synchronization—Managing data distribution across theuser-base, providing all users with the latest data, in real time—fromany device.

[0183] The live data is displayed in interactive windows inside theusers' browsers through the appropriate client:

[0184] AltioLive Client (ALC)—delivers a live, interactive, thick-clientstyle user interface within the user's browser.

[0185] Pervasive Client (APC)—delivers a page-oriented user-interfacerendered for user access through simple devices such as PDAs andmobiles.

[0186] Data Client (ADC)—delivers live, interactive data forpresentation through a DHTML interface.

[0187] Synchronization Engine (SE)

[0188] The APS is implemented as one or more clustered SynchronizationEngines (SE)s that are monitored and managed through the SE Admin Tool.

[0189] D. AltioLive Client (ALC)—Details

[0190] The AltioLive Client is a computer user interface that radicallyenhances how information can be displayed and updated over Internettechnology.

[0191] An ALC is composed of a number of components:

[0192] An internet client machine;

[0193] A web browser supporting a Java virtual machine;

[0194] A Java applet,

[0195] An XML Desktop Database.

[0196] These components are further described below and are shown inFIG. 1.

[0197] The ALC 100 typically fits into a configuration that consists ofa Web browser 103 in which the ALC runs as a small machine independentclient applet. The web browser would be running on an Internet Client104 that would be connected to a web server 105 via the Internet 102.The web server would be the gateway to the Internet for a number ofserver based web applications 106 a and 106 b etc. The Internet Clientcould be a personal computer running browser software, a WirelessApplication Protocol (WAP) mobile phone, a Personal Information Manager(PIM), or other information-viewing device. For live connectivity thesedevices must support some form of network connection (e.g. by using theJava 1.1 Virtual Machine). The personal computer would typically be aworkstation (e.g. PC compatible machine running a Windows™ operatingsystem, Macintosh™ or Unix™ workstation); the browser software could forinstance be Microsoft Internet Explorer™ version 5 (Seewww.Microsoft.com) or Netscape Navigator™ version 4 (Seewww.netscape.com).

[0198] In general the web server 105 would control the communicationwith the client using standard HTTP 109. Typically the ALC would useHTTP for the initial communication but could then switch to usingalternative communication protocols, such as TCP/IP or UDP, which bettersuit the application. In this way the ALC and the SE set up their owncommunication link 110.

[0199] One of the unique features of the ALC is that the Java Applet issmall enough to be downloaded and configured on the browser each timethe user starts a session with the application. This then gives richclient functionality without the need for add-ins and complexinstallation procedures.

[0200] Once the ALC is running on the client it creates an XML Database(inside the ALC space) on the desktop which not only stores all the dataimmediately required by the client but also has all the configurationinformation on how the interface should look and what the userpreferences are.

[0201] ALC—SE Interaction

[0202] The key to the uniqueness of the ALC is how it interacts with theSE. The SE is a server-side layer that serves the ALC with theconfiguration, data and updates.

[0203] As can be seen in FIG. 2, it is always the ALC that initiates thecommunication by requesting a page from the web server that contains theALC applet 201.

[0204] The web server will pass the request on to the SE, which willreturn a page to the client containing the ALC applet. The ALC is theninitiated in the client browser and from then on establishes andmaintains communications with the SE. To allow the user interface to bepersonalised, the user must make themselves known to the system and willtherefore be allocated a unique key that can be used to referencepersonal preferences. Upon request from the ALC the SE amalgamates XMLfrom a number of sources to send back to the ALC 204. Typically the SEcould get information from the following:

[0205] General ALC configuration XML;

[0206] User specific interface preferences;

[0207] Web Application data, from potentially many applications.

[0208] The SE can be configured to retrieve this information in a numberof different ways, including standard HTTP calls, SOAP, JDBC, Socket, orJMS. The ALC will use this data to render a display to the user 205. Theuser can then interact with the data in a familiar desktop environment.As the user interacts with the application the ALC may contact the SEfor additional data or it may initiate an update of the data.

[0209] When a user does something that requires additional data a chainof events takes place as described in FIG. 3. The important step is thatthe SE can be configured to be an intelligent cache of web applicationdata 304, thereby reducing the load on the web application itself. Anexample of this would be a news server. If the SE already has therequested news article then it doesn't need to interrogate the webapplication. The SE can also be configured to only return changed datatherefore reducing the amount of data sent 305. The SE uses a timestampmechanism to ensure that a client connection only receives “new” datachanges.

[0210] ALC Configuration

[0211] The ALC is totally configured with the use of industry standardXML. There are a number of aspects to the configuration:

[0212] Interface definition

[0213] Data Definition

[0214] User Preference Definition

[0215] Communications Definition

[0216] Referring to FIG. 4, the interface definition 401 defines how theapplication will be rendered by the client in terms of windows,controls, images etc. This is initially defined for the application butthen may be modified to take account of the user's specificconfiguration. The data configuration 402 defines the data to be servedto the client. This is the XML definition of data that will be stored inthe data section of the XML Desktop database. (The User Preferences 403,allow user specific requirements to be created and stored in the SE.These can then be used the next time the user logs on.

[0217] The Communication Definition will define how the ALC shouldinterface with the SE in terms of the underlying protocol. Typicallythis would be HTTP Streaming or Polling.

[0218] E. AltioLive—Synchronisation Engine (SE) Details

[0219] The Synchronisation Engine is a software application that canco-ordinate and control the interaction between multiple clients,multiple web applications or server data sources and multiplecommunication protocol types, while still being configurable viaindustry standard XML.

[0220] Some unique features of the SE are:

[0221] The ability to interface with existing web applications using avariety of protocols, including conventional HTTP, JDBC, SOAP, Socket;and JMS;

[0222] In built scalability to support large numbers of simultaneousclients and to keep them synchronised with each other and the webapplication;

[0223] In built fault tolerance through parallel clustering of SEs;

[0224] The ability to plug together multiple SEs and allow them todiscover each other and their data sources;

[0225] The ability to decouple the refresh rates of the web applicationsand clients;

[0226] The ability to communicate with a number of different clienttypes, for example Internet browser, WAP phone, Personal InformationManager;

[0227] Ability to pull together multiple web services;

[0228] The ability to transport XML data elements to targeteddestinations.

[0229] An SE is composed of a number of components:

[0230] A network server machine;

[0231] A server operating system;

[0232] A communications protocol stack;

[0233] A Java™ virtual machine;

[0234] The SE Java servlet control programme,

[0235] These components are further described below:

[0236] The SE would be located on a network server machine. Typicallythere would be a CPU, random access memory, permanent disk storage,ports for communicating with other servers on the local network, amanual input device and a display unit. Once the server was set up itwould generally be administered remotely via the comms ports, in whichcase the keyboard and VDU might be removed.

[0237] The server is designed to run an operating system that is storedon permanent disk and is loaded into memory at start-up. The operatingsystem would typically be Windows NT™ or Unix™ or Linux™, but could beany operating system that can support Javat™ Servlets. To communicateover the local/wide area network the server would require acommunications protocol stack such as TCP/IP.

[0238] The software to control the SE would also be stored on permanentdisk within the server and would also be loaded into memory as required.All the configuration information for the SE controlling software isstored as XML.

[0239] Communications

[0240] A key aspect of the SE is communications. The SE is able tocommunicate with back-end applications, with front-end clients and withother SEs. It can communicate at a number of different levels and in anumber of different modes. At the lowest level the SE controllingsoftware will need to know the network protocol by which it needs totalk to each client and application. For communication to backendapplications this could be HTTP, JMS, SOAP, Socket, or JDBC.Communication with the clients will typically be across the Internet andwould therefore be over HTTP, but in some scenarios could be over TCP/IPor UDP. The SE will need to know the network address of eachcommunications partner, for TCP/IP this would be the IP Address or theserver name which this then translated into a TCP/IP address.

[0241] SE Configuration

[0242] The SE would be configured from a number of XML configurationdefinitions. Referring to FIG. 4, the server configuration 401 defineswhat data pools are going to be available and the definitions of theservice functions required to interact with the web applications thatare enabled through the SE. The server configuration also defines thearchitecture of the SE in terms of clustering, security andcommunications.

[0243] The data configuration 402 defines the data to be served to theclient. This is the XML definition of data that will be stored in eachof the data pools. Each data pool is a transaction log, which trackschanges to the data set(s) held in the client.

[0244] The application configuration 403 defines how the applicationwill be rendered by the client in terms of forms, screen, images etc.This is initially defined for the application but then may be modifiedto take account of the users specific configuration.

[0245] The application default 404 will store system defaults such asrefresh rates and other variables. These will be set at start up.

[0246] Data Interaction

[0247] Once communications are established between the SE, clients andweb applications, the SE will need to transfer data between them. Thiscan be by a number of methods:

[0248] Push—This is where the SE propagates data to all parties thatrequire it. This is used to keep the clients in sync with webapplication data changes. Web applications can also be setup to pushdata to the SE.

[0249] Pull—This is where the SE polls for the latest data, on a timebasis or on user instigation. The client can also pull data from the SE.An example of a “Pull” is how changes to data on the web application arepropagated back to the web client via the SE. Typically a web page isonly refreshed when the user requests one and when it is refreshed allthe data is transferred from the server even if it hasn't changed. TheSE introduces a number of alternatives depending on the applicationrequirements. The SE can be configured to check for changed data atdifferent time intervals 404. If the SE detects a change 408independently of a RE (Rendering Engine/Layer) request 402, then it caneither cache the change or push it to all clients who currently requireit. Changes would only be able to be pushed to the RE if a suitablecommunications protocol was in place such as HTTP Streaming, TCP/IP orUDP.

[0250] Simple Configuration

[0251] The first embodiment of this invention, Synchronisation EngineSimple Configuration, is depicted in FIG. 5. This figure shows thesimplest configuration consisting of one SE server 504 which would beconnected to a number of applications 507 and optionally the web server508. It would also be connected to the Internet 503.

[0252] Complex Configuration

[0253]FIG. 6 demonstrates how multiple versions of the SE can be piecedtogether to form a scalable and fault tolerant network. This can be donewithout any code changes and with minimal configuration changes and theconfiguration that is required is all via XML. The SE system can bedeployed many times to produce a hugely scaleable and fault tolerantsystem. In this embodiment there are two main SEs 601 & 602, these wouldact as dual redundant servers providing a high degree of faulttolerance. Each SE would have independent links to the sourceapplications 604. The SE invention embodies code that will allow theseservers to keep themselves fully synchronised 603.

[0254] This approach provides a large degree of scalability by allowingthe SEs to be setup in a snowflake configuration. The two main SEs, 601& 602 would act as the hub and would then be connected to other SEs 605& 606 etc rather than directly to clients. Each one of these satelliteSEs could then be linked to a large number of clients. The SE inventionincorporates the propagation logic required to service this complexsnowflake configuration.

[0255] More SEs could be setup in parallel to provide additionalresilience and scalability. Also the snowflake configuration could beextended to have many layers thereby giving near infinite scalability.Although in the above-described embodiment, the client was based on aweb browser, it would be possible to have other types of user interfacesuch as a Wireless Application Protocol (WAP) phone or a PersonalInformation Manager (PIM). The SE can also be split over many CentralProcessing Units (CPUs) within the same server or over many servers.

[0256] F. Deploying AltioLive

[0257] The generic applet must be configured so that the XML databaselayer on the client displays the correct data for a particular user, inthe correct format and with window controls appropriate to that user,and in an optimal manner for the display capabilities of differentclient devices. The APS has responsibility for configuring the genericapplet. This is achieved via the XML Deployment Package (XDP). XDPscontain the definitions for the following AltioLive elements:

[0258] 1. Service Functions—define the data (XML data & related Imagedata) available to users from the Web Application and the mechanismsavailable to update the Web Application.

[0259] 2. Data Pools—define the mechanisms for live distribution of XMLdata updates to users.

[0260] 3. AltioLive-Views—define the live interactive user-interfacedelivered through the AltioLive Client. There can be multiple viewsaccording to user roles.

[0261] 4. Pervasive-Views—define the page-rendered user interfacedelivered through the Pervasive Client. There can be multiple viewsaccording to user roles and/or device capability.

[0262] 5. Data-Views—define the data and access available through theData Client for a DHTML user interface.

[0263] 6. Common elements—icons, desktops styles etc. for use acrossviews within the XDP. XDPs can be developed as self-contained entities.Typically a self-contained XDP is used where the views are tied to aspecific Web Application e.g. a contract resource application couldprovide a requirement-view, a resourcing-view and a phone-basedtimesheet entry-view. Self-contained XDPs are also used in deliveringthird-party components (e.g. a Chat or e-mail component) that areeffectively ‘plugged-in’ to application-specific XDPs. XDPs can alsomake use of definitions from other XDPs to define their views. Typicallythis is used where the views merge XML data from many applications intoa specific role-based view (e.g. a salesman sees a cross-system-viewcombining sales tracking data, customer management data and creditcontrol; the sales director sees a view combining aggregated sales data,personnel monitoring and campaign performance data) or to use elementsof a third-party

[0264] XDPS are developed within the AltioLive Development Edition (ADE)and then registered with the APS using the SE Admin Tool. Thisdistributes the XDP across all Synchronization Engines in a cluster tomake it available to users.

[0265] G. Security aspects of AltioLive

[0266] AltioLive combines best-of-breed security technologies andpractices to ensure a flexible, configurable and comprehensive securityarchitecture for all applications. AltioLive is designed to integratewithin existing security frameworks. It takes advantage of existingsession management and Secure Socket Layers and provides uniqueadditional security features to offer a robust and highly secureenvironment for all systems.

[0267] User Authentication

[0268] In AltioLive, users do not directly log-on to the APS. AltioLiveintentionally reuses the session object created in the webserver/application server in order to let you take advantage of:

[0269] existing authentication policies for the application;

[0270] best practices in user authentication;

[0271] and the existing investment in technology infrastructure

[0272] When the end-user accesses the application through a host Webpage, this page downloads the appropriate Client from the same webserver. The Client then contacts the APS, which uses the existingsession object (on the server) to determine the specific View and XMLdata to be served to the user. Even if the URL of the host Web Page isknown, the user cannot activate their connection with the APS unlessthey already have a valid session (including the necessary AltioLivespecific variables) on the Web server. Using the existing session fromthe Web server also prevents users from having to re-authenticate asthey cross boundaries in a distributed system. AltioLive allows users toauthenticate only once, regardless of the machine on which theapplication is deployed. To control who can connect to the APS,AltioLive leverages existing application servers' ability to enforcerules that govern whether a connection should be established based onclient IP access or protocol. This allows companies to decide if“Client” refers to AltioLive Client, AltioLive Pervasive Client, and theAltioLive Data Client

[0273] Unique User Views and Data Pools

[0274] Individual or groups of users can be assigned differentviews/windows, which can be populated by data specific to each group'sor individual user's need. Groups and/or individually registered userscan subscribe to different data pools in the APS. Users only see thedata to which they subscribe. In this way, AltioLive preventsunauthorized users from seeing sensitive data as well as allowing forunique user experiences/views. Through the APS, system administratorscan control which users see which data to ensure only the right datareaches the right users. For example, views could be configured fordifferent roles in an organization (i.e. Salesperson, Sales Manager,Credit Controller etc.) that provide access to a number of backendsystems—each role would have a view that restricts what functions areavailable and deliver only data that is relevant to their role.Specifying individual access levels through the APS allows productionsystems to be up and running very quickly with minimal configuration andno coding.

[0275] Firewalls

[0276] Use of standard HTTP and HTTPS connections between the Client andthe APS makes the technology transparent to most firewalls and does notrequire any relaxation of existing security policies. In highly secureenvironments where connections are restricted, the Client/APS connectionis specific and easily added to the allowable list of sites. Anadditional option for system administrators is to locate departmentalslave (APS) servers that sit inside the firewall to support one or moreusers (who therefore no longer have to connect to the Internet). Theslave server has a dedicated peer connection to its master APS that canbe additionally secured according to company security policies

[0277] Connection Security

[0278] Not only is it important that users are properly authorized andauthenticated when accessing data from the APS, but also that this datacannot be viewed while in transit. To avoid eavesdropping on connectionsbetween any connections to the APS, AltioLive offers users a number ofsecurity features:

[0279] Client to/from APS

[0280] AltioLive includes support for a Secure Sockets Layer (SSL) anddigital certificate implementation that provide authentication andprivacy via encryption in distributed APS applications. The Client/APSconnection takes advantage of current SSL technology including 56 and128 bit cipher strength connections. AltioLive is compatible withcertificate authorities that support X.509v3 certificates. This meansthat developers are free to use the vast majority of certificateauthorities available today.

[0281] In secure operation, the APS requires a digital certificate to beable to prove its identity to Clients and other servers. When a Clientcontacts the APS using SSL, they first request the server's digitalcertificate to prove its identity. Once the Client receives the servercertificate, identity is assured, and the Client and APS can confidentlysend data back and forth across the network. For highly secureenvironments, many installations need to also authenticate the Clientsaccessing the APS. For this reason, the APS SSL installation can beconfigured to also provide authentication for Clients and Web browser.This is called a two-way authentication and incorporates the samedigital certificate verification process. The major difference fortwo-way authentication is that the digital certificates are located inboth the Client and the APSs. Once certificates have been exchanged andmutually verified, both the Client and the APS can trust the identity ofthe other. Furthermore, once mutual authentication has been set up, aprivate channel can be created between the two hosts consisting ofencrypted data. Many systems will also require that the data which theClient receives from the APS and vice versa to be secure/encrypted. SSLallows both the APS and the Client to encrypt the data exchanged betweenthem. Potential hackers acquiring the data in transit are thereforeunable to understand it. Streaming data connections are designed to makeefficient use of secure connections to reduce server load as opposed toregenerating cipher keys for every request. Use of compressiontechniques on the data stream further enhances security while reducingthe overhead of encryption on the overall system. Both the Client andthe APS monitor connections to detect loss of connection. Clients'connections can be configured to either fail-over to another APS orrequire the user to re-establish their session through a login.

[0282] APS to/from APS

[0283] The APS can be clustered for load balancing in master/slaverelationships (as well as peer-balanced relationships). Theseconnections are effectively point-to-point connections that can useHTTP, HTTPS or socket connections to secure the interface. If the APSsare distributed in geographically different areas (not in the same datacenter behind the same physical firewall, for example), the SSL protocolprovides secure connections by allowing these APSs to connect over theInternet and authenticate each other's identity and by encrypting thedata between the APSs. For security above SSL hardware encryption can beused on the specific connection between servers. All APSs accessing thecluster must be pre-registered with compatible license keys, whichprevent spoofing of any of the servers.

[0284] APS to/from backend Web Application

[0285] The backend Web Application and the APS are usually in a closedand physically secured environment to prevent direct access to backenddata from any outside client device. For implementations where thesystem connects across the Internet to external Web Services, SSL anddigital certificates provide the necessary authentication and dataencryption to ensure that the Web Service is a proper entity and alldata transmitted is only decrypted and viewed by the intended recipient

[0286] Reliable Data Delivery

[0287] Data integrity and delivery is assured through a combination ofHTTP generated exceptions and the APS/Client timestamp mechanism. Allmessages from the APS to the Client are time stamped and sent across thenetwork using HTTP(S). Data from the APS is sent to the Client usingHTTP. Should a loss of network connectivity or a temporary hardwarefailure cause any data not to be received by the Client, the built-inhandshaking in the HTTP protocol generates an exception. Essentially, ifa message cannot be sent from the APS, the TCP/IP protocol generates anexception. This is generated in the server's Java Virtual Machine (JVM)and the exception is handled by the APS. The APS closes the connectionupon receiving an HTTP exception. The Client will automaticallyreestablish the connection with the APS (the reconnection strategy isconfigured through AltioLive Tools). When the connection isre-established, the Client requests all updates since the last timestampthat it successfully received, guaranteeing delivery of all messages inthe correct sequence. For streaming data to the browser, the Client isjust listening for data updates. In the case where it does not receiveany updates or a probe message in a configured interval, it will startits re-connection process to the APS. In the meantime, the APS willgenerate an exception when the probe message cannot be sent

[0288] Transaction Authentication

[0289] To prevent an unauthorized user submitting a transaction it iscommon to use forms of transaction authentication. This takes the formof access security/signature software on the client (sometimes evencoupled to physical security—e.g. card swipe, challenge/response devicesetc.) can add a security signature to any transaction. The AltioLiveClient can be configured to call-out to such applications beforesubmitting transactions to the server to either append the signature orencrypt the whole transaction.

[0290] Use of Shared Workstations

[0291] Unlike many solutions, the Client does not store any informationlocally on the workstation (configuration, data or even images). Thismeans that the user can safely access their application fromshared/networked platforms without worrying that their data isaccessible by others when they have logged-off. This is a key issue inthe access-anywhere features of Altio's technology. Standard sessiontime-outs can be used on the server to time-out inactive sessions. TheClient can also be configured to disconnect on logout and/or moving fromthe host page to prevent someone using the Back/Forward functions of thebrowser to reactivate the application (if it hasn't already timed-out).

[0292] Data Available to the User

[0293] The data available within the XML Desktop and visible to the useris configured at design time and enforced by the APS. Users cannotconfigure their Client to access additional data not presented to theirspecific View.

[0294] Protection for the User

[0295] For the end-user, the Client is implemented within the standardJava 1.1 Security model. AltioLive Clients therefore do not have accessto local data or services on the end-user's system and developers cannotundertake bespoke development to override the functionality of theClient. As an option, the Client can be ‘signed’ to give end-usersadditional comfort that the software can be trusted for use on thespecific application.

[0296] A Complete Security Architecture

[0297] In addition to all of AltioLive's security features, companiesmust also ensure that they secure the general environment in whichAltioLive is deployed. Such precautions include:

[0298] Securing the operating system: No security hole in the DNS,sendmail or any other potential entry points.

[0299] Securing File System: No general access to sensitiveconfiguration information

[0300] Securing Network: Use of firewalls and VPN

[0301] Securing Physical Environment of the Server(s): Only authorizedpersonnel have physical access to system

[0302] Separating Development and Production Systems

[0303] No Source Code Available on Production System

[0304] The combination of real desktop-like functionality in onlinesystems that users can access from anywhere, and the Internet becoming aproven and reliable medium for mission-critical communication is nowdriving companies to rapidly build new systems online as well as migrateexisting systems to pure Internet Protocol-based applications usingsoftware platforms like AltioLive. Companies deploying IP-basedapplications must take special care that implementations are done in asecure and highly reliable environment to protect the substantialcapital commitment required to build or to migrate any applicationonline. AltioLive is designed to take advantage of existing securityframeworks, such as session management, user authentication and SecureSocket Layers, reliable data delivery and transaction authentication,and it provides additional unique built-in security functionality tooffer the most robust and highly secure environments for developers andend-users at a fraction of the cost and time of alternative techniques.

[0305] H. Benefits of using AltioLive

[0306] With its XML based architecture, AltioLive eliminates all thechallenges posed by HTML, JavaScript and Dynamic HTML in the developmentof Internet applications.

[0307] Specifically, AltioLive provides companies the followingbenefits:

[0308] Increased User Functionality: AltioLive provides aclient/server-like environment directly inside the browser, giving usersthe same power as they have in traditional offline client/server-basedsystems. With AltioLive users have all the data they need at theirfingertips in real-time, allowing the functionality in the system to berichly interactive. Graphs, drag-and drop, sorting resizing anddynamically changing data are all available to users right inside thebrowser.

[0309] Enable Data delivery Across Devices: AltioLive allows end-usersto access Web applications from any Internet enabled mobile device(including Palm, WinCE, WAP phones, and Web TV)—freeing them from thetraditional PC-centric Internet experience. AltioLive applications canbe deployed almost anywhere as they are based on pure XML and can be‘tuned’ to meet people's various needs.

[0310] Savings on System Development: Using the AltioLive Designer tool,developers drag and drop lists, graphs, buttons, images, and designwindows with the use of their mouse. There is no coding required todevelop the front-end, and only minimal coding for the connectionbetween the front-end and the back-end. This frees up preciousprogramming resources to focus on building business logic rather thantedious and error-prone HTML AltioLive significantly shortensdevelopment cycles, to enable faster time-to-market with considerablecost savings. Companies using AltioLive for large development projectshave seen as much as 90% time and cost savings, equivalent to more thana million dollars in upfront cost.

[0311] Savings on System Maintenance: Since there is no code to bewritten for the front-end by the developers, AltioLive eliminates thechance of bugs through human error. Changes to the front-end can beimplemented immediately using the AltioLive Designer tool. Connectionsfrom the client to back-end servers are also handled by AltioLive andwhile some of the integration requires actual code from developers, mostof the tasks are automated by AltioLive. AltioLive reduces bugs andeliminates the need to have significant IT resources or consultants onhand whenever changes have to be implemented.

[0312] Savings on Bandwidth: AltioLive pushes data across the networkonly when the data actually changes. Even then, it only sends across thedata that needs to be updated, not entire pages, tables, graphs orwindows. Consequently, AltioLive-based systems substantially reduce thebandwidth used, saving companies substantial money on their bandwidthcharges.

[0313] Fast Performance: AltioLive-based systems deliver the initialdata set in compressed form to the client. Users immediately see anyupdates to the data as it changes from the back-end as well as when theymake any modifications themselves through the client. Most of the datawill initially not travel over any network to a database for processing,but instead reside on the client available to the user. The proximity ofthe data to the user gives faster performance than mostclient/server-based systems; it performs like a thick client

[0314] Ability to Prototype New Features: With AltioLive it is easy todevelop and prototype new features and make incremental changes. Thereis no coding involved when using the AltioLive Designer tool withXML-based Web services. The user interface, the logic between thedifferent windows and the connection to the back-end servers can beconfigured by the business person who will actually be using the system.

[0315] Customized and role-based views: Multiple views can be easilycreated for an application (e.g. basic vs. advanced or manager vs.employee) and be automatically distributed by individual or role.

[0316] White Label Applications: The look and feel of an AltioLiveapplication is determined by ‘skins’ that allow very fine control (atthe pixel level) of how applications look in the screen. The AltioLiveDesigner tool can tailor applications for a number of customers (i.e.incorporate their logos, borders etc.) to provide users with a uniquelybranded experience.

[0317] Secure Systems from Hackers: AltioLive provides securecommunication through standard SSL (Secure Sockets Layer) and HTTPS withthe Web server or application server doing the encryption and decryptionin the server, and the browser doing the same on the client side.Additionally, the AltioLive applet runs in a carefully protected ‘sandbox’ environment on the browser, preventing any ability to read/write tothe hard disk drive on the computer. AltioLive-based applications can beused from public locations, such as net cafes, libraries etc. because itis as harmless a plain HTML page and leaves no data cached behind.

[0318] Less Load/Stress on Back-end Servers: Changes to data in thedatabase are pushed out to the client in real-time, but only whenchanges occur and only the changed data is updated (not the wholewindow). This eliminates the need for users to constantly refresh thescreen and make calls to the database on the back-end, which todaycauses heavy load when numerous users access the system. As users modifythe data and submit new data back to the database, system administratorsuse the AltioLive Application Manager to configure how often this datais sent back to the database. This effectively allows systemadministrators to tune the system for optimal performance. Companiesusing AltioLive have reduced server load by as much as 90%. SinceAltioLive decreases the stress on the back-end servers, implementationsrequire less servers, or at least less CPU-intensive servers, whichreduces hardware costs by thousands of dollars. Additionally, as mostsoftware Licenses are based on hardware CPUs, significant savings comefrom reduced software license fees. With certain enterprise softwareLicense fees approaching $75-100,000 per CPU, a reduction of even one ortwo CPUs could save a lot of money.

[0319] Ability to Implement Changes Quickly: AltioLive allows companiesto instantly make changes, small or large, with virtually no coding onthe client and only limited coding on the connection from the client tothe server. This ability allows companies to adjust their systems ondemand, rather than leave them with less than adequate functionality asbusiness requirements change.

[0320] I. Glossary

[0321] Altio Presentation Server (APS)—The operational platform fordelivering live XML data to users through the Altio clients.

[0322] AltioLive Client (ALC)—Client that delivers a windows style liveinterface within a browser.

[0323] AltioLive Pervasive Client (APC)—Multi-device client that rendersonto devices such as WAP, Web TV, PDAs.

[0324] AltioLive Data Client (ADC)—Data-only client (i.e. nopresentation) for use with dynamic HTML user interfaces.

[0325] A ‘client device’ is any device which can be controlled over anetwork and has some means by which a human can view and/or interactwith it. It could be as simple as a network controllable light bulb andswitch or more complex, such as screen & keyboard based personalcomputers. Software on the client device can be embedded or installedonto the device or delivered on demand to the device over a network.

[0326] A ‘data source’ is any source of data potentially relevant to anetwork based application and includes basic data feeds (e.g. newsheadlines, equity quotes, sensor measurements) and more complexenterprise applications (e.g. Client Relationship Management, HumanResources, Enterprise Resource Planning and Accounting systems). Any‘data source’ can also be independently or simultaneously a ‘datareceiver’ and accept structured data and commands from the presentationserver.

[0327] Domain Name System (DNS)—The Domain Name System (DNS) is anInternet directory service. DNS is used to translate between domainnames and IP addresses, and to control Internet email delivery. MostInternet services rely on DNS to work. If DNS fails, web sites cannot belocated and email delivery stalls.

[0328] HTTP Hyper Text Transport Protocol—A request-response typeprotocol that specifies that a client will open a connection to a serverthen send a request using a very specific format.

[0329] HTTPS Secure Hyper Text Transport Protocol—A request responsetype protocol with encrypted data using Secure Socket Layer (SSL)

[0330] Java Virtual Machine (JVM)—A self-contained operating environmentthat behaves as if it is a separate computer. For example, Java appletsrun in a Java Virtual Machine (VM) that has no access to the hostoperating system.

[0331] A network based application is any application that can run overa physical or virtual network and where the client device is generallyindependent of the data source. A ‘networked based application’ includesconfigurations where the network is virtual (e.g. both the ‘presentationserver’ and the “client device” are on the same physical machine), orwhere the ‘network’ is established on occasion (e.g., as would be thecase for many synchronizable handheld devices).

[0332] SE Admin Tool—An in-browser tool to administer and monitorSynchronization Engines.

[0333] Synchronization Engine (SE)—The server-side component thatintegrates AltioLive with Web Applications and delivers live XML data.View what a user sees and interacts with in AltioLive-basedapplications—i.e. their interface to the application.

[0334] Virtual Private Network (VPN)—A VPN is a private connectionbetween two computers to transport private data over a public networklike the Internet A VPN offers encryption, tunneling, authentication andaccess control effectively preventing data being intercepted in

[0335] Appendix 1

[0336] “Getting Started with AltioLive” from Altio Inc.; Chapter 3Titled ‘The AltioLive Presentation Server’

[0337] In this chapter we will look at the AltioLive architecture andlearn more about how the ROS demonstration application was created.

[0338] AltioLive applications are deployed through the AltioLivePresentation Server (APS). This integrates with a back-end application(that could be supporting an existing HTML interface) and also supportsthe AltioLive Client In FIG. 7 one can see the comparison betweentraditional HTML applications and AltioLive's technology. The deploymentarchitecture has a number of key components:

[0339] AltioLive Client—a small footprint Java applet that runs withinbrowsers supporting a Java Virtual Machine (v1.1 and above)—i.e.Microsoft Internet Explorer 4 or better, Netscape Navigator 4 or better.

[0340] Synchronization Engine—Java servlets that maintain thecommunication between one or more back-end applications (through ServiceFunctions) and the AltioLive Client. The Java servlets operate in a Java1.3 servlet environment, and support JSDK 2.0 to allow for installationon common Application Servers.

[0341] SE Admin—a browser-based tool used to configure and monitor oneor more clustered Synchronization Engines.

[0342] Configuration—XML files and images that configure the applicationinterface presented in the AltioLive Client; XML files to configure theSynchronization Engine.

[0343] In Operation

[0344] The end-user logs on to the site and accesses an HTML page(called the host page). This reserves space for the Altio Desktop on thepage, and references a small footprint Java applet (the AltioLiveClient).

[0345] The AltioLive Client requests the Synchronization Engine to serveits View—an XML definition of the look, feel and operation of theuser-interface. If the Synchronization Engine is not already running, itwill read the server configuration file (altioserver.xml) to initializeitself.

[0346] Using session parameters, the Synchronization Engine determineswhich AltioLive application and View the user is trying to access. Itcreates the xml definition of the View by combining the View definitionfile (appview.xml) with any retained preferences (e.g. window positions)from the user's last session. If the View refers to system images (e.g.skins, buttons etc) then these are also served to the client so that itcan render the interface to the user.

[0347] Note that the Sync Engine cannot initialize the back-endapplication; it assumes that any back-end application is alreadyrunning.

[0348] Service Functions and Data Pools

[0349] While requesting the View, the AltioLive Client also requests theinitial data to populate the client-side XML Desktop. At this stage theSynchronization Engine loads the application configuration file(altioapp.xml) to create the service functions and data pools requiredto serve data to the View. Using the View's initial data definition file(app-veiw_data.xml) the XML data is requested from the back-endapplication (via Service Functions) and served to the client.

[0350] Service Functions can use either an HTTP connection, or beimplemented using Java Messaging Service (JMS).

[0351] As part of its Application Configuration, the Client requests theApplication Images (i.e. backgrounds, button images, icons and skins),which are served from the Sync Engine. These can be packed intocomposite image files to minimize download time.

[0352] At the same time the AltioLive Client is subscribed to any DataPools so that they receive relevant updates to the initial data set.Data Pools are shared across clients, and track changes from the initialdata sent to each client Data Pools collect updates from the back-endapplication ether by polling to a URL at regular intervals (HTTPpolling) or by having updates streamed through JMS, an HTTP streamingconnection, or Socket (direct connection). This is configurable per DataPool.

[0353] Independently to the Data Pool configuration, the Client canreceive updates by regular polling or through HTTP streaming (note thatsome browsers do not support streaming connections). The user can submitupdates through the Client. These are mapped onto Service Functionsissued by the Synchronization Engine, which in turn submit the updateddata to the back-end application. These update methods can map toexisting HTTP post methods on the back-end application if available.

[0354] Every Data Pool must have a service function associated with itto provide initial data; however the reverse is not necessarily true, assome service functions will provide static data, which is not expectedto change during the users session.

[0355] If there are images that are data related (e.g. thumbnails), thenthe Image Data is requested from the back-end application when theClient requests it, via image-specific service functions.

[0356] User Preferences

[0357] If the user changes the state of their desktop (window positions,state) the changes can be optionally posted to the SynchronizationEngine and saved locally or on a shared store (e.g. in an externaldatabase through a JDBC connection). This allows the users desktop to berestored when they next log in. This setting is made in the Sync Enginefor all applications.

[0358] The ROS Demonstration

[0359] Firstly, there is no specific back-end application installed. Thedemonstration is built entirely using the AltioLive Developer Editionand takes advantage of the bundled AltioLive Development Prototyping Kit(ADPK). This simulates the back-end application through its:

[0360] Login handler—used to create the session when the user logs on,and serve the AltioLive application host page (called AltioLogin).

[0361] XML Database—a general-purpose configurable in-memory XMLdatabase (called AltioDB) that accepts scripted updates (hence theability to create dynamic price changes) and persists data to flat files(hence any bids you have made reappear when you next log on).

[0362] Logging-on

[0363] When you select the demonstration option, the login handlergenerates the log-on screen. When you log on, the login handler createsa session object with specific tags to identify the application and theView. In this case ros (which you typed in as Application) is theapplication and the View is preconfigured in the Login Handler toroslive for all users. Once you've logged-on, the login handler servesthe Richmond Office Supplies Host Page (roshtml.txt) which in turndefines the space for the AltioLive Desktop and invokes the AltioLiveClient The AltioLive Client then connects to the Synchronization Engine,which accesses the session parameters to determine that you are usingthe ros application with the roslive View.

[0364] The Initial View

[0365] The Synchronization Engine serves the View file,ros/views/roslive.xml, to the client, which defines:

[0366] The open windows i.e. This is AltioLive and Offers and Bids

[0367] The three minimized windows i.e. Offers I Watch, My Bids and MyOffers For Sale

[0368] The windows that can be activated by the user e.g. Create New Bid

[0369] The controls on each window and how they are populated with datafrom the XML desktop.

[0370] The event-action rules e.g. open Create New Bid for the selectedrow in the LIST when the toolbar button is clicked.

[0371] If you had previously accessed the View, then it will beautomatically modified according to your saved user preferences e.g.window positions and states.

[0372] The Initial Data

[0373] The Synchronization Engine serves the initial data (to populatethe XML desktop) according to the information associated with the View(FIG. 8). This is defined in the Designer, on the View tab, Initial Datanode. In this case there ate four service functions used to get initialdata. Of these, GET_FORSALE and GET_WATCH both subscribe to datapools.

[0374] The Synchronization Engine substitutes the Server Commands forthe XML data returned from the Service Function specified in the SVRCMD.

[0375] The catalog data is static and so the server command just invokesthe GET_CATALOG service function, which returns the XML data for allcatalog items (e.g. the product id, description, thumbnail etc).

[0376] The items for sale and their corresponding bids, however, need tobe updated live in the user interface so you can see new offers or bidsor changes to data as they are made. Therefore the include statement notonly invokes the GET_FORSALE service function to return this initialdata set but also subscribes to the NEW_FORSALE Data Pool so that anyupdates are streamed to the client. The individual portfolio of itemsthat you are interested in also is subscribed to a Data Pool in order toshow you things that you have dropped into the watch-list. Moreinformation on this is in the next section.

[0377] Service Functions And Data Pools

[0378] The application configuration file, ros/altioapp.xml, is used toconfigure the Service Functions and Data Pools for the application. Allservice functions in ROS are HTTP-based. An example Service Function isshown in FIG. 9.

[0379] This definition states that when the GET_CATALOG Service Functionis invoked, an HTTP URL request is executed with the specifiedarguments. In this case, the target is the XML Database (AltioDB) andthe arguments specify that the CATALOG data set should be returned.

[0380] Note: Service Functions do not define the format of XML data thatis returned and one of the features of AltioLive is that it accepts anyvalid XML data.

[0381] The datapool in FIG. 10 is used to get updates of items, whichthe user has placed, on their watch list. The ‘Enter Text’ fieldcontains the XPath information used in the Filter. (It is only displayedhere so that you can see the entire XPath statement used in the Filter).This ensures that only items that the logged on user has added to theirlist are passed into the datapool. The AltioLive Client uses this tocreate a personalized watch list. The subscription is filtered byuser-id so that the user does not see the items others have added totheir portfolios. The predicate @USR=$(session.logon.name) syntaxcontrols this. The Pollrate specifies how often updates should be passedto the client, in this case every 1000 milliseconds (1 second).

[0382] Submit New Offer

[0383] When you submit a new offer from the “Create New Offer For Sale”window you select a product from the list, enter details in the variousfields, and click the “Submit” button. The Submit button has an actionrule that invokes a NEW_SALE Service Function, as shown in FIG. 11.Again, the ‘Enter Text’ field includes the full URL argument (which ispartially obscured in the upper box). This Service Function creates anew SALE_ITEM element in the FOR_SALE table. Again the target is AltioDBand in the arguments the GUID assigns the unique ID (which AltioDBcreates when adding an element) to a SALE_ID attribute. ONSUCCESS andONFAILURE define the message that you see if the update succeeds orfails. The APP_ID is used to ensure the service call goes to the correctback-end application, and the SELLER_ID is set to the logged on${session.logon.name} taken from the session parameters. The SRVPARMlist maps the named fields in the “Create New Offer For Sale” window tothose expected by the back-end application. In this case we have thefreedom to use the same names. For example, the data for product isscraped from the control NM=“PROD”—the row selected in the “Product”column in the list of products. The Data attribute created by the serverin the new SALE_ITEM with this data in it is also specified as PROD.

[0384] The SALE_ITEM created by this Service Function will looksomething like this: <SALE_ITEM SALE_ID=”S05” SELLER_ID=”Mary” PROD=”Lever arch” PROD_ID=”ID06” QTY=”1” PRICE=”11” CURRENCY=“USD”SH_TRMS=”FOB” PORT=”North Pole” CTRY=”SWE” EXP_(—) DATE=”20001022”COMMENT=”Beyond words.”>

[0385] Where you need to create data that is not shown on the window, asis the case with the product ID (PROD_ID), this is achieved by usinghidden fields or columns. Thus for the PROD_ID the column is included inthe “Select a Product” list but it has a width of 0, and hence is notdisplayed.

[0386] Submit New Bid

[0387] When you submit a new bid from the “Create New Bid” window, the“Create New Bid” window shows the details of the “Offer For Sale” itemthat was selected, and allows the relevant details for the bid to beentered. Once the information is entered in the fields the “Submit”button is clicked. The button has an action rule, which calls a NEW_BIDService Function as shown in FIG. 12.

[0388] This Service Function differs from the previous example(NEW_SALE) in that the BID element has to be inserted as a child of theSALE_ITEM that it corresponds to. Hence the TARGET is set toSALE_ITEM—where the SALE_ID is equal to the SALE_ID of the offerselected in the “Offers and Bids” window, which is passed to the “CreateNew Bid” window. NAME=BID specifies that a BID element is to beinserted. GUID=BID_ID specifies that the BID_ID is set to the generatedunique ID. The remaining SRVPARMs are set to the data as input in the‘Create New Bid’ window. The BID inserted under SALE_ITEM by thisService Function will look like this <SALE_ITEM SALE_ID=“S05”SELLER_ID=“Mary” PROD= “Lever arch” PROD_ID=“ID06” QTY=“1” PRICE=“11” CURRENCY=“USD” SH_TRMS=“FOB” PORT=“North Pole”  CTRY=“SWE”EXP_DATE=“20001022” COMMENT=“Beyond words.”>   <BID BID_ID=“B13”BIDDER_ID=“Steve” PROD=“Lever arch” PROD_ID=“ID06” QTY=“1” PRICE=“6.30”  CURRENCY=“USD” SH_TRMS=“FOB” PORT=“South Pole”   CTRY=“FIN”EXP_DATE=“20001022”  COMMENT=“Ring the bell when delivering.”/></SALE_ITEM>

[0389] Image Handling

[0390] The AltioLive Client downloads data images on demand. An exampleof this can be seen by looking at the catalog of products that isdisplayed when the “New Offer” button is clicked. When the “Create NewOffer For Sale” window is displayed, the images for the first four itemsin the product list are downloaded. If you scroll down the list you willsee a slight delay (usually about half a second) as new images aredownloaded for the products in the lower part of the list. Notice thatif you have scrolled through the list before, all of the images havealready been downloaded, and thus the response is instant. This methodof image handling results in improved performance, allowing applicationsto include rich image content without incurring a long initial downloadtime. The code required to achieve this is given below. <COLDATAFLD=“THUMB” TYPE=“IMG” W=“40” IMGSVRCMD=“GET_APPIMG”/>

[0391] This element specifies the column of the “Select a product” list,including a GET_APPIMG image server command —shown in FIG. 13. The imageserver functionality of the client handled when this Service Function iscalled, i.e. when the image is first displayed. The data for the listthe column specifies is in //ITEM as its node. In the column a datafield of //ITEM, THUMB is specified. This contains the directory pathand name of the image e.g. THUMB=“img/CalculatorTN.jpg”.

[0392] Appendix II

[0393] Integrating AltioLive

[0394] from Altio Limited; Volume 4 Chapters 1-5 of the AltioLive UserDocumentation.

[0395] Introduction

[0396] Welcome

[0397] This document explains the system operation of AltioLive and howit is configured to integrate with existing applications. This coversvarious areas, from configuring controls to advanced issues of style,recommended practices and optimising performance.

[0398] Many examples in this document are drawn from the ROS (RichmondOffice Supplies) example application. This allows you to see how toachieve particular results, and you can see working examples in theapplication.

[0399] The examples show the XML code of the application configurationand data, as explained in the API Guide. Each XML attribute mapsdirectly on to the matching property of the control in the Designer.Each control corresponds to an XML element.

[0400] Readers should be familiar with the other Altio documents—inparticular:

[0401] Getting Started

[0402] Online Help

[0403] Technical Overview

[0404] Describes the overall operation of AltioLive and how thecomponents of AltioLive integrate and operate to create a live dynamicinterface.

[0405] Glossary

[0406] Provides abbreviations and icons used throughout the document

[0407] Application Server Integration

[0408] Configuration of the Sync Engine to support creation of ServiceFunctions to integrate one or more applications with the Sync Engine. Itcovers:

[0409] Initial Data

[0410] Datapools

[0411] Client to Application updates

[0412] Image data

[0413] Service Functions

[0414] Communication options

[0415] Data Sync

[0416] Addresses the mechanisms used to update data (through Datapools)on the Client. It covers:

[0417] Timestamps

[0418] Datapool longevity

[0419] Deleting data

[0420] AL_IDs

[0421] Client update

[0422] Hosting the Client

[0423] Invoking the Applet from the Host Web page. It covers:

[0424] Standalone

[0425] Debug mode

[0426] Browser compatibility

[0427] Dynamic mode

[0428] Links to Javascript

[0429] Logon Process

[0430] Addresses the mechanism of logon process and session creation. Itcovers:

[0431] Session Creation

[0432] Altio Logon Process

[0433] Independent Logon

[0434] Skins

[0435] Customization of the look of the Client through the use of Skins.It covers:

[0436] The Outline Skin

[0437] Showing the window is active

[0438] Resizable windows

[0439] Window controls buttons, toolbar buttons and icons

[0440] Composite images

[0441] Creating a Custom Jar

[0442] Building a custom Jar to increase the download speed andefficiency.

[0443] Sync Engine Management

[0444] Covers

[0445] The Sync Engine Admin Tool

[0446] The Application Manager

[0447] Data Referencing and XPath

[0448] Some examples of different methods of using XPath.

[0449] Configuring Controls

[0450] Tips on using the Designer to configure controls.

[0451] Data Filtering

[0452] Examines methods of selectively providing data.

[0453] More Information

[0454] Further information on configuring AltioLve is contained in theonline AltioLive API Guide and Operating and Maintaining AltioLive.Information on installing AltioLive is provided in the AltioLive ServerInstallation Guide. Support can be reached by sending email tosupport@altio.com.

[0455] To send feedback to Altio on this manual, send email to:feedback@altio.com

[0456] CHAPTER 1—Technical Overview

[0457] The system architecture of an AltioLive application is shown inFIG. 14.

[0458] Where:

[0459] The application interface is accessed through a Host Page, whichinvokes the AltioLive Client applet. The Client is a small footprintapplet targeted at Java 1.1 Virtual Machines (IE4 and above, Netscape 4and above) for maximum browser compatibility.

[0460] The Client accesses the AltioLive Sync Engine. This isimplemented as Java Servlets for use on Servlet engines, which supportJSDK 2.0 to allow installation on common Application Servers.

[0461] The look, feel and operation of the Application interface isdefined through the Altio XML API (see AltioLive API guide). Inestablishing communication, the Client requests the Sync Engine to serveit with this definition which it creates from the Default XML(predefined by Altio), the Application Configuration XML and userpreferences from any previous sessions.

[0462] As part of its Application Configuration, the Client requests theApplication Images (i.e. backgrounds, button images, icons and skins),which are served from the Sync Engine. These can be packed into one ormore composite image files to minimize download times.

[0463] The Sync Engine also processes the Data Configuration XML. Thisspecifies Service Functions (defined in the Server Configuration XML)that request the Initial Data from the Application to be served to theClient where it is saved in the XML Desktop and rendered to the user.

[0464] If there are images that are data related (e.g. thumbnails)rather than Application related, then the Image Data is requested fromthe Application when the Client specifically needs it using imagespecific Service Functions.

[0465] The Data Configuration XML also subscribes the Client toDatapools within the Sync Engine. The Application updates the InitialData by either polling for, or streaming, Data Updates from the SyncEngine. The mechanism and frequency is configured per Datapool in theApplication Configuration.

[0466] Datapools are shared across Clients and track changes from theInitial Data sent to the first Client. The status of a specific Client'sXML Desktop in relation to subscribed Datapools and data on theApplication is maintained through a timestamp/sequencing mechanism.

[0467] New Data is either polled-from or streamed-to the Clientasynchronously to maintain the XML desktop.

[0468] Updates from the Client (i.e. data that has been entered by theuser) are passed to the Sync Engine and posted to the Applicationthrough a Service Function that can be mapped on to its existing HTTPpost interfaces. The effect of the update is reflected through thepreviously described Datapool mechanism and/or through userconfirmation.

[0469] If the user changes the state of their desktop (window positions,state) then these are posted to the Sync Engine. According to the ServerConfiguration, these are saved locally, saved in an external databasethrough a JDBC connection or posted to the Application.

[0470] Sync Engines can be clustered/distributed to serve largecommunities of users using a Master-Slave configuration.

[0471] CHAPTER 2-Application Server Integration

[0472] Overview

[0473]FIG. 15 shows the interaction between the Sync Engine and theApplication.

[0474] There are three key areas:

[0475] 1. Data Service Functions that request the Initial Data and thenpass updates to the Application

[0476] 2. Image Service Functions that request Data-specific images

[0477] 3. Datapools, which update the Initial Data

[0478] Initial Data

[0479] The Data Configuration defines the Initial Data set for theClient. This invokes one or more Service Functions to request data fromthe Application that is then served to the Client

[0480] An example Data Configuration is shown below: <ALTIO>  <DATA>  <USER NM=“to_be_set_by_SyncEngine”/>   <INCLUDE SVRCMD=“GET_CATALOG”/>  <INCLUDE SVRCMD=“GET_FORSALE” SUBSCRIBE=   “NEW_FORSALE”   SUBSCRIBE_ARGS=“”/>  </DATA> </ALTIO>

[0481] The INCLUDE elements can be considered as effectivelysubstituting the XML data elements returned by the Service Functionbefore the data is passed to the Client In the case of the GET_CATALOGService Function, the catalog data it returns is static data (i.e. notupdated during the user session) and therefore it does not subscribe toa Datapool. In the case of the GET_FORSALE data, this is ‘live’ datasubscribed to the NEW_FORSALE Datapool. The name used in a SUBSCRIBEshould correspond to a Datapool definition in the ApplicationConfiguration file.

[0482] The SUBSCRIBE_ARGS attribute can be used to apply filters to aDatapool i.e. to restrict which updates to the data set are passed ontothe Client. In this case no filter is set so all Clients get all dataupdates. The value for SUBSCRIBE_ARGS can derive from session parametervalues using the ‘{ }’ syntax (see API Guide).

[0483] The USER NM attribute is optional and is a mechanism to make theUser Id (from the session) accessible in the Client. An example is givenin the Configuring Controls section.

[0484] Datapools

[0485] Datapools provide a method for distributing updates to multipleClients. Each Datapool definition creates a single Datapool, which isinstantiated when the first Client subscribes.

[0486] Datapools track changes to the Initial Data sent to the Clientand received from the Application using timestamp information in theDatapool and in the Initial Data.

[0487] In a Master-Slave configuration, the Master Sync Engine receivesthe updates to the Datapools from the Application. The Slave Sync Enginecommunicates with the Master Sync Engine to receive the updates in itsDatapools. The Client(s) polls for or is streamed to the updates in theDatapools of the Slave Sync Engine.

[0488] In a single Sync Engine configuration, the updates are receivedin the Datapools of the Sync Engine from the Application. The Client(s)either polls for or is streamed to the updates from the Datapools. Anexample Datapool definition from a Server Configuration is shown below:<DATAPOOLS>  <DATAPOOL NM=‘NEW_SALE’ CACHESIZE=‘800’  ARCHIVEFILENAME=‘C:\syncengine\Data\ArchiveNewNews.txt’>    <MASTERDATAPATH=‘//FOR_SALE’ SENDTIMESTAMP=    ‘N’>     <MASTERHTTPPOLLRATE=‘2000’ URL=“http://server.name/servlet/com.altio.demodb.DemoDB”      URLARGS=“ACTION=GET&amp;PARENTTAG=      FOR_SALE” />    <TIMESTAMP ELEMENT=‘//FOR_SALE’ ATTRIBUTE=‘TIMESTAMP’ TYPE=‘INTEGER’FORMAT=‘#’/>    </MASTER>    <SLAVE>     <SLAVEHTTP POLLRATE=“2000”/>  </SLAVE>  </DATAPOOL> </DATAPOOLS>

[0489] This defines the NEW_FORSALE Datapool where: NM Specifies thename of the Datapool. CACHESIZE Specifies the cache size of theDatapool. ARCHIVEFILENAME Specifies the relative pathname of the filewhere the old entries to the Datapool are archived. For example, ifCache size is set to 800, the last 800 entries are held in the Datapool.All the earlier entries are archived to a file.

[0490] Attributes for Master Sync Engine communication with theApplication DATAPATH Specifies an XPath definition that specifies thesubset of elements to extract from the application XML and then pass onas data updates. It defaults to the full XML returned by theapplication. SENDTIMESTAMP Specifies whether the Sync Engine should sendthe Timestamp with the update. MASTERHTTP, Defines the communicationoption - in this case HTTP MASTERHTTPSTREAM, Polling. Note . . . TheCommunication is defined per MASTERSOCKET Datapool. URL Defines URL of afunction on the Application that is used to request updates. Thisattribute is specified if the communication protocol is set to HTTPPolling or Streaming. URL ARGS Specifies additional parameters passed inthe HTTP Post Method —necessary if the Application function is non-specific (i.e. has multiple methods). This attribute is specified if thecommunication protocol is set to HTTP Polling or Streaming. POLLRATEDefines the poll rate interval for HTTP polling in milliseconds. Thisattribute is specified if the communication protocol is set to HTTPpolling. IP Defines the IP address of the machine on which the back endApplication is installed. This attribute is specified if thecommunication protocol is set to Socket. PORT Defines the port for thecommunication protocol is set to Socket. This attribute is specified ifthe communication protocol is set to Socket. ELEMENT Specifies theelement within the returned data update that would contain theTimestamp. The element should be specified as an XPath query statement.ATTRIBUTE Specifies the attribute within the element specified thatwould contain the Timestamp value. TYPE Specifies the return type forthe Timestamp. It can be set to INTEGER or DATE type. Format Specifiesthe Format in which the Timestamp is returned with the data update.

[0491] Attributes for Slave Sync Engine communication with the ClientSLAVEHTTP, Defines the communication option - in this case HTTPSLAVEHTTPSTREAM, Polling. Note: The Communication is defined SLAVESOCKETper Datapool. POLLRATE Defines the poll rate interval for HTTP pollingin milliseconds. This attribute is specified if the communicationprotocol is set to HTTP polling. PORT Defines the port for thecommunication protocol is set to Socket. This attribute is specified ifthe communication protocol is set to Socket.

[0492] In this case this is a polled definition, so an HTTP request ismade every 2 seconds by the Master Sync Engine to the Application withthe following parameters:

[0493] action=GetForSaleServlet&TIMESTAMP=nnnnn

[0494] Where TIMESTAMP is the last value for the Datapool (see nextChapter).

[0495] On receipt of an update, the Master Sync Engine adds the updateto the queue of updates to be sent to the Slave Sync Engine. The SlaveSync Engine polls for the Update every 2 seconds. On receipt of anupdate, the Slave Sync Engine adds the update to the queue of updates tobe sent to the Client(s).

[0496] Client to Application Updates

[0497] The Client updates the Application (i.e. to add/modify/deletedata) by invoking a Service Function with parameters. This is defined inthe View Configuration.

[0498] An example update request from a View Configuration is shownbelow: <BUTTON H=“30” W=“70” X=“90” Y=“270” CAPTION=“Submit” > <ACTIONRULES TRIGGER=“CLICK”>   <ACTIONRULE DESC=“Description of actionrule”>    <CONDITIONS/>     <ACTIONS>      <ACTSERVER CMD=“NEW_BID”WINDOWSTATE=      “HIDE” DATATYPE=“WINDOWDATA”/>     </ACTIONS>  </ACTIONRULE>  </ACTIONRULES> </BUTTON>

[0499] When the button captioned ‘Submit’ is pressed, the Client invokesthe Service Function named NEW_BID and passes (as parameters) the nameand value of all controls within the current window that have an NMattribute defined (i.e. they are named controls). There are twoexceptions:

[0500] IMAGE—named-image passes blank values

[0501] LIST—lists use the named columns of the selected row. If no rowis selected then a blank value is used for each named column. The listitself does not have to be named.

[0502] Service Functions return a success/fail status back to the Clientwith an optional message and optional parameter name which are treatedas follows:

[0503] If successful and there is no message, then nothing is displayedto the user.

[0504] If successful and there is a message, then this is displayed in a‘success’ pop-up window.

[0505] If unsuccessful and there is a message defined, then this isdisplayed in a ‘failed’ pop-up window.

[0506] If unsuccessful and there is no message, then nothing isdisplayed to the user.

[0507] If unsuccessful and there is a parameter control name, then theassociated control is selected (i.e. cursor positioned on field inerror).

[0508] Image Data

[0509] Data related images (e.g. thumbnails of catalog items) arerequested from the Application (by the Client) through image requestService Functions. To avoid start-up delays, these images are onlyrequested when they have to be rendered in the user interface, e.g. if alist contained images, only the visible images are requested. If thelist is scrolled then more images will be requested. Images are cachedon the Client once received and are not re-requested.

[0510] An example image request from an Application Configuration isshown below: <PANEL>   <IMAGE NM=“IMAGE” DATAFLD=“THUMB”IMGSVRCMD=“GET_APPIMG” H=“80” W=“80” X=“260” Y=“180”DATA=“//ITEM[@PROD_ID=‘{SALE_LIST@PROD_ID}’]” BORDERW=“5”FILLCOL=“#FFFFFF”/>   <TEXT H=“20” W=“100” X=“120” Y=“20”CAPTION=“Product:”  EDITABLE=“N” DATAFLD=“PROD”/>   ... </PANEL>

[0511] The DATAFLD specifies the attribute name in the element selectedin DATA that holds the name of the required image. The IMGSVRCMDspecifies the Service Function used to request the image (using thevalue of the attribute specified by the DATAFLD). In this case it willpass the value of the THUMB attribute in the specified element of DATA.

[0512] Service Functions

[0513] Service Functions define HTTP requests used to send and/orrequest data from the Application (for Initial Data and/or updates).

[0514] Whilst they are defined independently from the Application(thereby allowing multiple use of the Service Function) it's useful toconsider some specific instances for:

[0515] Requesting Initial Data.

[0516] Requesting an update on the server.

[0517] Requesting an image.

[0518] They are designed to provide simple integration with theApplication and (in the case of updates) to map onto existing HTTP postrequests.

[0519] To have an acknowledgement message sent to the client aftercalling a service function, use the following steps:

[0520] 1. In the Application Manager, edit the Service function.

[0521] 2. Under Acknowledgement, set the Source to Response.

[0522] 3. Click OK to accept, then validate and update theApplicationConfig.xnl file.

[0523] Requesting Initial Data

[0524] An example Initial Data request (GET_CATALOG) Service Functionfrom a Application Configuration is shown below:  <SERVICENM=“GET_CATALOG”URL=“http://server.name/servlet/com.altio.demodb.DemoDB”URLARGS=“ACTION=GET&amp;PARENTTAG=CATALOG” ADDQ=“N” DOCTYPE=“XML”GETDATA=“Y/>  <SERVICE>

[0525] Where: URL Defines URL of the Application function that will beinvoked by the Service Function. URL_ARGS Defines the additionalparameters - necessary in this case, as the Application function isgeneral purpose. DOCTYPE Specifies the type if data that is expected -in this case XML data. GETDATA Specifies whether the data returned bythe Application should be served to the Client - in this case it is

[0526] The Application in responding to this Service Function shouldsupply XML formatted data. If the Datapool mechanism is to be used (i.e.to feed dynamic updates to the client) then the first tag must include aTIMESTAMP attribute e.g.: <CATALOG TIMESTAMP=”12890”>  <ITEMPROD=“Calculator” PROD_ID=“ID01” PRICE=”4.49”  DESCR=“The bestcalculator around” />  <ITEM PROD=“Chair” PROD_ID=“ID02” PRICE=”69.50”DESCR=“Comfortable and relaxing...” />  ... </CATALOG>

[0527] Refer to next Chapter for use of timestamps.

[0528] Requesting Updates to the Application

[0529] An example data update request (NEW_BID) Service Function from anApplication Configuration is shown below:  <SERVICE NM=“NEW_BID”URL=“http://server.name/servlet/com.altio.demodb.DemoDB”URLARGS=“ACTION=NEW&amp;PARENTTAG=SALE_ITEM&amp; PARENTID=SALE_ID&amp;NAME=BID&amp;GUID=BID_ID” ADDQ=“Y” DOCTYPE=“XML”GETDATA=“N” ACKSRC=“HEADER” ACKTYPE=“SUCCESS” ACK=“Added record”>  <ONSUCCESS MSGSRC=“DEFINE” MSG=“Your bid has been   accepted”/>  <ONFAILURE MSGSRC=“DEFINE” MSG=“There was a problem processing yourrequest”/>   <SRVPARM SERVER=“SALE_ID” CLIENT=“SALE_ID”/>   <SRVPARMSERVER=“BIDDER_ID” CLIENT=“{logon.name}”/>   <SRVPARM SERVER=“QTY”CLIENT=“QTY”/>   <SRVPARM SERVER=“PRICE” CLIENT=“PRICE”/>   ...  </SERVICE>

[0530] Where: DOCTYPE Specifies the type of data that is expected - inthis case general text (i.e. not XML or an image). GETDATA In this casespecifies that it should not be returned to the Client. Note: It shouldnot be set to “Y” if the DOCTYPE is not “XML”. ADDQ Defines whethersingle quotes should be put around the parameter values passed with therequest. ACKSRC Defines the source of response message. Set it toRESPONSE to search for a response message defined in the Application.Set it to HEADER to search for Altio specific parameters (see below) inthe HTTP response header. Set it to NONE if no message is required.ACKTYPE Defines whether the Sync Engine should search for the responsemessage after the Success or Failure of the Service Function. ACKDefines the Application defined response message that the Sync Enginesearches for if the ACKSRC is set to RESPONSE. ONSUCCESS The Sync Enginecan be set to serve the Client a message in a pop- MSGSRC up window, ifthe result of the Service Function was successful. Defines the source ofmessage. Set it to DEFINE to send a user defined message. Set it toHEADER to return the Altio specific parameters (see below altio.message)in the HTTP response header. Set it to NONE if message is not required.ONSUCCESS MSG Defines a confirmation message. The Sync Engine serves themessage to the Client in a pop-up window on the success of the ServiceFunction. The Text can be set only if Source is set to DEFINE. ONFAILUREThe Sync Engine can be set to serve the Client a message in a pop-MSGSRC up window, if the result of the Service Function was a failure.Defines the source of message. Set it to DEFINE to send a user definedtext. Set it to HEADER to return the Altio specific parameters (seebelow altio.message) in the return HTTP header. Set it to NONE if nomessage is required. ONFAILURE Defines a message. The Sync Engine servesthe message to the MSG Client in a pop-up window on the failure of theService Function. The Text can be set only if Source is set to DEFINE.SRVPARAM Defines the parameters that are passed (and their order) withthe request. This also maps Client defined parameter names (which arederived from control names) to Application parameter names.

[0531] In this case, his would result in an HTTP request with thefollowing parameters:

[0532] action=NewBid&SALE_ID=‘..’&BIDDER_ID=‘..’&QTY=‘..’&PRICE=‘..’

[0533] Note: The second parameter is a special case. CLIENT=“[UID]” isused to define that the User ID defined in the session parameters ispassed as the value for BIDDER_ID. If other parameters from the sessionare to be used, then the { } syntax can be used to specify sessionparameter e.g. {logon.name} would have the same effect as [UID].

[0534] The above method is good for integrating on a preexistingApplication Interface and provides mechanisms for confirming thesuccess/failure of the update.

[0535] If the Application Interface can be modified, then theApplication can set Altio specific parameters in the HTTP responseheader as follows: altio.status Set to: 0 indicates Success 1 indicatesfailure (no message) 2 indicates failure (with message). altio.messageIf status = 2, then this contains descriptive text that will bedisplayed to the user in the pop-up error window. altio.errfld Containsthe server parameter name that caused the error. This is converted backinto the Client control name and passed back to the Client so it canre-position back on the field.

[0536] Requesting Images

[0537] An example image request (GET_APPIMG) Service Function from anApplication Configuration is shown below:  <SERVICES>   <SERVICENM=“GET_APPIMG”URL=“http://server.name/servlet/com.altio.demodb.GetImageServlet”ADDQ=“N” DOCTYPE=“IMG” GETDATA=“Y”>   <SVRPARM SERVER=“APP”CLIENT=“{logon.app}”/>   <SVRPARM SERVER=“IMG” CLIENT=“IMG”/>  </SERVICE>   ...  </SERVICES>

[0538] Where: URL Defines URL of the Application function that willreturn the image. DOCTYPE Specifies the type if data that is returned -in this case an Image (i.e. JPEG, GIF etc). GETDATA Specifies that thedata requested by the Service Function will be returned to the Client.SVRPARAM Specifies the mapping between parameters passed by the Clientin the service request to the Sync Engine into parameters passed by theSync Engine to Application. Note: This must use CLIENT = “IMG”.

[0539] In this case, this would result in an HTTP request being madewith the following parameters:

[0540] IMAGEURL=imageurlname

[0541] Downloading Data on Demand

[0542] Normally all data (apart from context-dependent images) isdownloaded onto the client at the same time as the applet. However,there are some circumstances where you may want to have datadownloading, only if (or when) it is required by the user.

[0543] If you have an action rule set up on a list so that when a userdouble-clicks on a row they get a list of related information in aseparate window. If the related information is very large then it may beefficient to download it on demand so that time is not used downloadinginformation that may not be required by the user.

[0544] 1. Downloading sets of data on demand.

[0545] This can be achieved by taking the datapool subscription for thedata out of the viewname_data.xml file and implementing it as anACTSERVER action rule, triggered by a particular event.

EXAMPLE

[0546] Rearrange the ROS demo data into a file of the sale items and afile of the bids and alter the service functions so that sale items areinitially sent to the client and the relevant bids are only sent when aparticular sale item is selected.

[0547] The action rule is placed on the list of sale items and lookslike:

[0548] Trigger ONCHANGE

[0549] Action ACTSERVER

[0550] Command=GET_BIDS

[0551] Data type=STRING

[0552] Data=‘{SALE_LIST@PROD_ID}’

[0553] Data tag=PROD_ID

[0554] Window state=RESUME

[0555] where Data tag and Data roughly correspond with attribute andvalue.

[0556] The GET_BIDS service function has an XPath target statementrequesting bids with a particular PROD_ID.

[0557] 2. Updates for the downloaded data set—data routing

[0558] We can also assign a datapool to update this data. If we set thedatapool as non-transient: <DATAPOOL NM=‘SECURITIES_POOL’ FILTER =‘/SECURITIES/SECURITY[/USERS/USER[@USER_ID=${session.logon.name}]/USERSYMBOL/@NM=@SYMBOL]’ ... </DATAPOOL>

[0559] By calling a service function through an ACTSERVER action rule wecannot subscribe to a datapool so we cannot get updates. Luckily this ischanging in the next software release where we have introduced the ideaof non-transient datapools. We can create an entry in a second datapoolthat acts like a temporary subscription to the main datapool containingall the updating data. Hence we can temporarily request updates for aparticular set of data when we open a window and automatically cancelthe updates when the window is closed.

[0560] Communication Options

[0561] The mechanism used for Service Functions is always the HTTP POSTMethod. This Sync Engine will accept GZIP and ZIP compression formats inresponse to these requests to minimize traffic volumes from theApplication.

[0562] Three mechanisms are available to provide New Data to theDatapools:

[0563] HTTP Polling—wherein the Sync Engine periodically polls theApplication for updates.

[0564] HTTP Streaming—wherein the Sync Engine opens an HTTP Request andthe Application sends updates as they occur.

[0565] Socket—as per streaming but using the underlying socketmechanism.

[0566] The mechanism is specified per Datapool.

[0567] Of these three mechanisms, the first is normally the easiest toimplement against an existing Application (as it requires least changeto the Application architecture). The latter two are mechanisms forrapidly changing data Note: None of these three mechanisms acceptcompressed data format (they should only be handling small data sets)

[0568] If the SOCKET mechanism is used then the Sync Engine willautomatically add an additional parameter in the HTTP requestSOCKET=“nn” to specify the socket address for the Application to use inresponding with data.

[0569] Data Formats

[0570] Date and time data is expected in AltioLive in the format

[0571] YYYYMMDDTHHMMSS+x

[0572] Where the Time part (THHMMSS+x) is optional, and the GMT offsetof the server (+x) is also optional.

[0573] Other Notes

[0574] 1. The Sync Engine does not check that the returned data matchesthe DOCTYPE.

[0575] 2. The Sync Engine will output a warning if the parametersprovided by the client do not match those defined in the ServiceFunction.

[0576] 3. URL_ARGS if specified are posted before SVRPARAM values.

[0577] 4. When using HTTP Polling, the first poll occurs immediately.

[0578] 5. The Sync Engine is inactive until the first user connects.

[0579] Whilst one Service Function can be used for Initial Data it isoften better to define a number of Service Functions if:

[0580] There are multiple Datapools in use

[0581] Data is separately time stamped

[0582] Service Functions are shared across a number of ApplicationConfigurations which define an interface which uses different data sets

[0583] Data is sourced from multiple Applications.

[0584] Its better to have small Datapools for specific data rather thanan all-embracing large Datapool. This allows more control over refreshrates and avoids conflicts over XML attribute names.

[0585] Its better to filter data on the Sync Engine than on the Client.

[0586] CHAPTER 3—Data Sync

[0587] Overview

[0588] The Datapool mechanism is used to update multiple Clients from asingle update from the Application—wherein only the XML element that haschanged is sent to the Client.

[0589] Timestamps

[0590] Each Datapool has an associated Timestamp. This is in the form ofa long integer value or in Date/Time format.

[0591] The Timestamp is initially set when the first Client subscribesto the Datapool and receives its Initial Data (in which there must be aTIMESTAMP=nn attribute in the initial tag).

[0592] Thereafter, the Timestamp is updated whenever, the Sync Enginereceives updated data from the Application whether by polling (in whichcase it passes its current value in the request) or through streaming.The new Timestamp is specified as an attribute in the initial tag of theresponse.

[0593] The interpretation of the Timestamp is determined by theApplication and is specific to each Datapool (i.e. AltioLive does notspecify whether the number is milliseconds, seconds, next sequencenumber etc). However, the Timestamp must get numerically larger witheach update.

[0594] The Timestamp is sent an integer or date/time format. It shouldsupport the expected lifetime of an Application. In the unlikely eventthat the Timestamp has to be reset, then the Sync Engines would need tobe reset.

[0595] A Timestamp parameter accompanies the Data Update request sent bythe Sync Engine to the Application. In some cases, while integrating anexisting Application with AltioLive, it would be necessary to excludethe Timestamp parameter from the Data Update request.

[0596] By default, the Application returns the Timestamp value as anattribute of the parent node of the data update posted by theApplication. However, the Timestamp can be retrieved from a specifiedelement attribute from the data update received from the Application ina specified format.

[0597] If for any reason, an update is received with a duplicate of anearlier Timestamp then the Sync Engine will output a warning message.

[0598] Datapool Longevity

[0599] The Datapool effectively has an entry per timestamp. The size ofthe Datapool is determined through the CACHESIZE attribute. By defaultthis is set to 800 entries, which means that the last 800 updates areheld in the Datapool.

[0600] The required size of the Datapool depends on the frequency ofupdate to Clients and the frequency of update from the Application. Ifthe Client were to poll at 3-second intervals and the Applicationcreates updates at a rate of 2 per second, then it should be set to atleast four times the rate (i.e. 4*3*2=24) to provide contingency.

[0601] The last number of updates equal to the quarter of the cache sizeper Datapool are cached in memory. Earlier updates are archived to disk.For more details see the Datapool topic in the API guide.

[0602] Deleting Data

[0603] To update an XML element or insert a new XML element in the XMLDesktop, the Application simply has to supply the element through theDatapool mechanism.

[0604] However, to delete an element, the AL_ACTION=DELETE attributemust be added to the element (specifying sufficient attributes touniquely identify the element) For example, the following XML updatesthe description of the chair and deletes the calculator: <CATALOGTIMESTAMP=“12891”>  <ITEM PROD=“Calculator” PROD_ID=“ID01” PRICE=“4.49”AL_ACTION=“DELETE”   DESCR=“The best calculator around” />  <ITEMPROD=“Chair” PROD_ID=“ID02” PRICE=“69.50”   DESCR=“Comfortable andrelaxing and now in brown suede” /> </CATALOG>

[0605] AL_IDs

[0606] Data elements that are updated in the XML Desktop need to beuniquely referenced and AltioLive uses an AL_ID attribute to define aunique key for each element The Sync Engine through the DATAKEYSdefinition adds these AL_IDs.

[0607] An example Datakeys definition from a Server Configurationfollows: <DATAKEYS>  <DATAKEY NM=“ITEM” PREFIX=“CAT”>   <FIELDNM=“PROD_ID”/>  </DATAKEY>  <DATAKEY NM=“SALE_ITEM” PREFIX=“SALE”>  <FIELD NM=“SALE_ID”/>  </DATAKEY>  <DATAKEY NM=“BID” PREFIX=“BID”>  <FIELD NM=“BID_ID”/>  </DATAKEY> </DATAKEYS>

[0608] Where:

[0609] DATAKEY NM

[0610] Specifies the name of an XML element tag—in this case <ITEM.../>

FIELD NM

[0611] Specifies the attribute name within the element whose value isused as the key—therefore this attribute should have unique valueswithin all elements of the same type.

[0612] PREFIX

[0613] Specifies a prefix that is added to differentiate betweendifferent types of element that might otherwise have non-unique values.

[0614] The result of the first DATAKEY definition on the following datawould be as follows: <CATALOG>  <ITEM PROD=“Calculator” PROD_ID=“ID01”PRICE=“4.49”   DESCR=“The best calculator around” />  <ITEM PROD=“Chair”PROD_ID=“ID02” PRICE=“69.50”   DESCR=“Comfortable and relaxing...” /></CATALOG>

[0615] becomes: <CATALOG>  <ITEM AL_ID=“CAT_ID01” PROD=“Calculator”PROD_ID=  “ID01” PRICE=“4.49”   DESCR=“The best calculator around” /> <ITEM AL_ID=“CAT_ID02” PROD=“Chair” PROD_ID=  “ID02” PRICE=“69.50”  DESCR=“Comfortable and relaxing...” /> </CATALOG>

[0616] Client Update

[0617] Datapool updates are either polled from the Sync Engine by theClient or streamed to the Client.

[0618] In the case of Polling: the Client polls the Sync Engine usingits current Timestamp(s) (either the Initial Data or last successfulpoll). In response to the poll, the Sync Engine will send all updates(for all Datapools subscribed by the Client) subsequent to theTimestamp.

[0619] In the case of Streaming, the Sync Engine maintains a queue ofClients that are subscribed for streamed updates. As the Datapool isupdated, the relevant updates are added to a queue for each Client.

[0620] Other Notes

[0621] 1. The Client Queue is fixed length (16 entries). In the event ofa queue being full (only likely if the Application generates updates ata high rate and/or the Client is subscribed to many Datapools), Datapoolupdating will suspend for up to 30 seconds to allow the queue to clear.If the queue is still full after 30 seconds, the Client session isterminated.

[0622] 2. In the event of the Client Queue being full/disconnected,warning messages are output to the Sync Engine log.

[0623] CHAPTER 4—Hosting the Client

[0624] Overview

[0625] The AltioLive Client applet is hosted in a host HTML pagespecific to each customer Application and may occupy the whole page orshare the page with HTML defined areas (usually frames) around theapplet space.

[0626] Debug Mode

[0627] If the application is to be run in debug mode, the debug versionof the applet needs to be specified, and the types of debug messagegiven can be configured. <HTML>  <HEAD>   <TITLE>Demo</TITLE>  </HEAD> <BODY topmargin=“0” leftmargin=“0” marginwidth=“0” marginheight=“0”>  <applet code=“com/altio/AltioApp.class”    align=“baseline”width=“800” height=“600”    archive=“lib/clientDebugServer.jar”>   <param name=“CONFIGFILE” value=“Demo.xml”>    <param name=“STANDALN”value=“Y”>     <param name=“DEBUG” value=“SYSTEM APPLET CONFIG PAINT!PAINTTRACE !ACTIONRULE !SERVERIO !TRACKING !PARSING !XPATH UNASSIGNED”/>   </applet>  </BODY> </HTML>

[0628] The values: SYSTEM APPLET CONFIG PAINT |PAINTTRACE |ACTIONRULE|SERVERIO |TRACKING |PARSING |XPATH UNASSIGNED, are the available typesof error messages. Those prefixed with an exclamation mark are turnedoff.

[0629] where: archive Specifies the applet file name. Code Specifies themain class for the client applet and must be set tocom/altio/AltioApp.class. align, width, Define the location and fixedsize of the AltioLive Desktop area within height the page. The size ofthe Altio desktop can be set relative to the size of the browser windowusing the % setting e.g. “width = “100%” height = “99%” Param Parametervalues that define the name of the XML Application Configuration (Note:there should be an equivalent Data Configuration file in this case nameddemoStandaln_data.xml) and that the applet is operating in standalonemode.

[0630] Browser Compatibility

[0631] The above invocation works for most browsers. There is currentlyone known exception for Netscape 4.x running on the Macintosh. It onlysupports Java effectively with the MRJ plug-in installed. Also the Embedtag must be used instead of the Applet tag with additional parameters.See htmltemplate.txt for an example of how to detect and support this.

[0632] When using AltioLive in Dynamic mode it is necessary to changethe HTML to reflect the connection to the Sync Engine.

[0633]FIG. 16 shows a typical example of this integration.

[0634] The user logs on to the Application through its Logon process.For the demos provided with AltioLive, an Altio Login page is provided.(This is purely for demonstration purposes and is not intended for usein final applications.) Either directly (from the Logon page) orindirectly (through other pages/menus) the user invokes the URL of theHost page. The Application then constructs and serves the Host page HTMLthat invokes the Client with necessary parameters. (See Chapter 6 LogonProcess for further details.)

[0635] Once downloaded, the Client establishes communication with theSync Engine to access the Application definition (personalized for thatuser) and the data required. This requires the Sync Engine to access theuser's session which it should inherently have access to either throughco-location on the application server or through session propagation ina clustered application server environment

[0636] An example of the applet invocation HTML would be: <appletcode=“com/altio/AltioApp.class”   align=“baseline” width=“800”height=“600”   archive=“clientDebugServer.jar”>   <param name=“appsrc”value=“......altioserver URL”>   <param cookie=“cookie string”></applet>

[0637] where the major differences are: Appsrc Specifies the URL of theSync Engine instead of a local file. Cookie Specifies cookie string(necessary for some Macintosh deployments because cookie information isnot always inherently accessible to Java applets). This should not beused for LINUX client deployments.

[0638] Debugging the Client—During system integration it is possible toenable debug output by the Client to the Java Console. Contact AltioTechnical support for details.

[0639] Javascript—Action Rules within the Application Configuration caninvoke Javascript e.g.: <BUTTON H=“30” W=“80” X=“200” Y=“15” CAPTION=“ALTIO.COM”>  <ACTIONRULES TRIGGER = “CLICK”>   <ACTIONRULEDESC=“Default Action”>    <CONDITIONS>     ...    </CONDITIONS>   <ACTIONS>     <ACTJAVASCRIPT METHODNAME=“MYMETHOD”     ARGS=“BTNCLICK”>    </ACTIONS>   </ACTIONRULE> </ACTIONRULES></BUTTON> a final

[0640] Or can invoke a Javascript function e.g.: <BUTTON H=“30” W=“80”X=“200” Y=“15” CAPTION= “CALCULATOR”>  <ACTIONRULES TRIGGER = “CLICK”>  <ACTIONRULE DESC=“Default Action”>    <CONDITIONS>     ...   </CONDITIONS>    <ACTIONS>   <ACTION_APP CMD=“JAVASCRIPT”  SCRIPT=“calculator( )” />   </ACTIONS>  </ACTIONRULE> </ACTIONRULES></BUTTON>

[0641] The actual Javascript method will be invoked asynchronously in aseparate thread (in order to keep the applet responding). The Javascriptaction rule returns immediately and the actions continue with the nextaction if there is one. For this action rule to work a MAYSCRIPT tag isneeded on the APPLET tag in the HTML page hosting the applet.

[0642] E.g. <applet code=“com.altio.AltioApp” align=“baseline”width=“1041” height=“702” viewastext archive=“runthis.jar” mayscript>

[0643] Note: Currently there is no mechanism in place to make use of thevalue returned by the Javascript method, so the Javascript call shouldbe seen as a one-way call (which is suitable for most cases).

[0644] Other Notes

[0645] 1. The Application Server environment manages the session ‘life’.If a session expires and the Client is still active the user can beredirected to an HTML page (e.g. a Logon page) configured in the ServerConfiguration file.

[0646] 2. The Sync Engine can be configured to issue probe messages tothe Client that let the Client know the Sync Engine is still ‘live’.

[0647] 3. Parameters can be passed to Javascript.

[0648] 4. Use of Javascript may add additional compatibility issues.

[0649] CHAPTER 5—Logon Process

[0650] Session Creation

[0651] The Sync Engine requires access to the session on the Applicationserver. Hence a session must be created before invoking the applet fromthe Host Page. The user logs on to the Application through its Logonprocess. This establishes a shared session on the Application server.

[0652] The Default Altio Login Process

[0653] The Logon process used by the Altio Demonstration applications isdescribed below and is also shown in FIG. 17. The subsequent sectiongives examples and recommendations to help you code your own Logonmechanism. The Altio Logon HTML page creates a session by communicatingto a Java servlet, which takes the parameters of user Name, Password,and the Application name as entered. Password and Application name areverified against the AltioLiveDemo.xml file. Once the correct parametershave been entered, a user session is created by the servlet so thatuser-specific data is displayed and the correct user preferences areused. There is also the option of loading different XML configurationfiles, which could depend on what is entered in the Application field asin the example, or some other parameters such as user type.

[0654] The Altio Logon process is implemented as described below.

[0655] 1. The user loads the logon HTML page in the browser, by typingthe URL or following a link.

[0656] 2. The Logon page prompts the user to input user Name, Passwordand Application name.

[0657] 3. When user clicks ‘OK’, a communication link to the LogonServlet is established.

[0658] 4. The Logon Servlet verifies the user Name, Password andApplication name.

[0659] 5. If the logon information is correct, the Logon Servlet createsa Session Object with a unique Session ID. The Session ID is stored onthe Application server with the session lifetime. The Logon Servlet alsostores the parameters, AL_logon.name and AL_logon.config in the SessionObject

[0660] 6. The name of the Client applet along with the Session ID (as acookie) is passed to a Host HTML, page.

[0661] 7. The Host HTML page then invokes the Client. It sends theSession ID and the Logon request to the Sync Engine.

[0662] 8. The Sync Engine restores the Session Object with the SessionID. It retrieves the user Name and Application configuration file namefrom the Session Object As a part of the Logon request, the user is thensubscribed to the appropriate Datapools.

[0663] 9. The Client now sends an initialisation request to the SyncEngine accompanied by the Session ID.

[0664] 10. The Sync Engine requests Initial Data from the Applicationdatabase.

[0665] 11. The Sync Engine reads the Application configuration from theApplication configuration file.

[0666] 12. The Application configuration along with user preferences andthe Initial Data is sent to the Client in response to the initializationrequest

[0667] 13. After the initialization process, the Client sends the firstData Update request to the Sync Engine. The Data Updates are eitherstreamed to or polled from the Client. If the streaming mechanism isused, the streaming connection is opened in response to the first DataUpdate request and new data, if available, is sent to the Client. If thepolling mechanism is used, the first poll occurs after the logon and newdata, if available, is sent to the Client

[0668] In the above process, the propagation of the Session ID at eachstage is essential, since the Sync Engine can restore the session if ithas received the Session ID.

[0669] Independent Logon

[0670] In your application you may have an existing Logon process or youmay wish to write one. This logon mechanism must also create thesession. You don't need the AltioLiveDemo servlet and XML files once youlog on through your own Logon handler. The Host page needs to bemodified accordingly. If you would like an example HTML logon page andthe Java servlet that it calls, please contact Altio Technical Support.

[0671] If no Logon process is required, then you can directly type theURL of the HTML page that calls a Java servlet. This servlet mustperform the following tasks.

[0672] Creating a session with appropriate parameters

[0673] Passing the Client applet name along with the Session ID as thecookie to the Host HTML page

[0674] When a session is created, the following tags need to beincluded:

[0675] logon.name—holds the user name

[0676] logon.conf—holds the name of the view configuration XML (client)

[0677] logon.app—holds the APPID as defined in the Sync Engine Admintool.

[0678] Further tags specific to your application may also be included.

[0679] This means that anyone with an internet connection couldconceivably use your application. It also means you won't be able totrack which users are using the application.

[0680] A Technical Note detailing the No login Handler is available fromAltio Tech Support.

1. A presentation server which enables a client device to run a networkbased application by sending structured data from one or more datasources to software on the client device, wherein the presentationserver decouples the client device from the data source by (i)insulating the data source from needing to handle directly any display,data storage, data querying or communications functions relating to theclient device and (ii) insulating the client device from needing tohandle communications functions which are specific to the data source.2. The presentation server of claim 1 which enables (i) the data sourceto indirectly configure any display, data storage, data querying orcommunications functions relating to the client device and (i) enablesthe client device to indirectly communicate with the data source.
 3. Thepresentation server of claim 1 in which communication to the data sourceis carried out locally or over a network and in which interaction canoccur via services provided by the data source.
 4. The presentationserver of claim 1 in which communication to the data source is carriedout locally or over a network and in which interaction can occur viamessage queues to which the data source publishes and the presentationserver subscribes.
 5. The presentation server of claim 1 in whichcommunication to the data source is carried out locally or over anetwork and in which interaction can occur via message queues to whichthe presentation server publishes and the data source subscribes.
 6. Thepresentation server of claim 1 in which communication to the data sourceis carried out locally or over a network and in which interaction occursvia direct calls to the data source's application programmable interface(API) where the underlying system provides the low-level protocol. 7.The presentation server of claim 1 in which communication to the datasource is carried out locally or over a network and in which interactionoccurs via direct calls to one or more databases on the data source. 8.The presentation server of claim 1 in which communication to the datasource is carried out locally or over a network and in which interactionwith the data source is loosely coupled.
 9. The presentation server ofclaim 1 which insulates the data source from needing to handle directlyany display, data storage, data querying or communications functionsrelating to the client device by communicating with client software onthe client device which comprises: (a) a communications layer to sendand receive messages over the network; (b) a database layer to store,and allow querying of, the structured data; (c) a rendering layer whichgenerates, from the structured data in the database layer, data for auser interface; in which the client software is self-contained toprovide all of the communications, local data storage/querying andrendering resources needed to run the network based application on theclient device.
 10. The presentation server of claim 1 which also allowsthe data source to handle indirectly any display, data storage, dataquerying or communications functions relating to the client device byforwarding communications from the data source to client software on theclient device.
 11. The presentation server of claim 1 which by virtue ofstrictly separating the data source from the client device allowsbusiness logic of an application to be fully independent of thepresentation logic on the client device, such that the data source neednot even know of the existence of a client device even though it may bea necessary part of the network application.
 12. The presentation serverof claim 1 which by virtue of strictly separating the data source fromthe client device allows presentation logic of a client device to befully independent of the business logic on the data source, even to theextent that the client device need not even know of the existence of adata source even though it may be a necessary part of the networkapplication.
 13. The presentation server of claim 1 which insulates theclient device from needing to directly handle communications functionswhich are specific to the data source by translating messages from theclient device to a form suitable for the data source.
 14. Thepresentation server of claim 1 which insulates the client device fromneeding to directly interpret raw data provided by the data source bytranslating messages from the data source to a form suitable for theclient device.
 15. The presentation server of claim 1 which insulatesthe data source from needing to directly manage updates of thestructured data held on the client device by receiving a single dataupdate from the data source and being solely responsible for identifyingall client devices that need that data update, and sending theappropriate updating data to all of the client devices that need it. 16.The presentation server of claim 1 which insulates the client devicefrom needing to know the quantity or configuration of multiple datasources to which the presentation server is connected, by aggregatingdata from multiple data sources into a single data stream for eachclient device.
 17. The presentation server of claim 1 which maintains adata stream per client device in which the data is pushed over apersistent connection to the client device over the network as soon asit is available.
 18. The presentation server of claim 1 which maintainsa data stream per client device in which the data is sent to the clientdevice over the network in response to regular or ad-hoc pollingrequests from the client device.
 19. The presentation server of claim 1which compresses the data received from the data source prior to sendingthe information to the client device.
 20. The presentation server ofclaim 1 which encrypts the data received from the data source prior tosending the information to the client device, thus insulating the datasource from the enhanced security needed to allow a remote client deviceto run the network application over a public or insecure network. 21.The presentation server of claim 1 which decrypts the data received fromthe client device prior to sending the information to the data source,thus insulating the data source from the enhanced security needed toallow a remote client device to run the network application over apublic or insecure network.
 22. The presentation server of claim 1 whichinsulates the data source from needing to manage updates of thestructured data held on the client device by regularly polling the datasource for changes.
 23. The presentation server of claim 1 whichinsulates the data source from needing to directly manage distributionof streaming data to multiple client devices, where the data sourceneeds only to provide a single stream to a presentation server which inturn broadcasts the information in a scalable fashion to multiple(potentially more than tens of thousands) of client devices that may inturn be connected to the presentation server at different performancerates over the network.
 24. The presentation server of claim 1 whichinsulates the data source from needing to handle communicationsfunctions specific to different client devices by having a genericcommunications capability (data receipt/acknowledgement/response)enabling it to communicate with multiple client browsers, multipleclient device types and across multiple bearers.
 25. The presentationserver of claim 1 which insulates the data source from needing to handlecommunications functions specific to different client devices by havinga generic display capability by being able to download to the databaselayer one or more of the following, each configured appropriately for adestination display, device type and bearer: such as panels, windows,controls, data binding to the controls and event models.
 26. Thepresentation server of claim 1 which can process a request by the clientdevice for an update to a data source and return an indication ofwhether the update was successful as indicated by a response from thedata source.
 27. The presentation server of claim 26 in which, if theupdate failed, the data source may optionally provide furtherinformation about the reasons for the failure in a way that can bedisplayed or interpreted by the client device.
 28. The presentationserver of claim 1 which can process a request by the client device foran update to a data source and return an indication of whether theupdate was successful even if the data source does not directly respondwith a success or failure indication.
 29. The presentation server ofclaim 28 which can be configured to automatically generate responses tothe client device on behalf of the data source.
 30. The presentationserver of claim 28 which can process a request by the client device fora single transaction update to multiple data sources and return anindication of whether the update was successful.
 31. The presentationserver of claim 30 which can process a request by the client device fora single transaction update to multiple data sources in such a way thatall data source updates are only confirmed once each data source haspreliminarily indicated that the update would succeed.
 32. Thepresentation server of claim 31 in which failure of any one of thetransaction updates causes all the transaction updates to be cancelledand a failure response to be returned to the client device thatrequested the transaction.
 33. The presentation server of claim 31 inwhich a preliminary validation of all transactions causes alltransactions to be confirmed and returns a success indication to theclient device that requested the transaction.
 34. The presentationserver of claim 1 which returns the message that results in the userinterface at the client device being updated at the same time as itissues a message that results in the user interface of different clientdevices being updated in the same manner.
 35. The presentation server ofclaim 1 which can update marginal portions of the database layer in aclient device by sending, instead of an entire structured data treehierarchy, a key which identifies the part of the structured data treewhich has changed.
 36. The presentation server of claim 1 which canupdate a database layer by altering, in real time, configuration dataheld in the database layer which defines how the structured data can beinteracted with from within the user interface.
 37. The presentationserver of claim 1 which can prioritise updates to a client device thatis returning on-line after an absence.
 38. The presentation server ofclaim 1 which can update the database layer by re-initialising all ofthe structured data on a client device that is returning on-line afteran absence by applying rules to determine if re-initialisation isappropriate.
 39. The presentation server of claim 1 which stores updatedstructured data in a transaction log record from which a client can pullupdates.
 40. The presentation server of claim 1 which stores updateddata in a transaction log record and pushes updates as appropriate tothe client device.
 41. The presentation server of claim 1 which is ableto send updating data to different client devices at different times orfrequencies.
 42. The presentation server of claim 1 which can beconfigured to skip unnecessary intermediate updates to streaming datafor devices whose connection or client device is too inefficient toreceive and process every update.
 43. The presentation server of claim 1which can maintain a statefull connection with the client device. 44.The presentation server of claim 43 which maintains a statefullconnection with the client device by routing a unique, incrementingnumber to the client device, which the presentation server logs inrelation to all data updates, so that when the client device returnson-line from an absence, the client device sends the latest number itreceived back to the presentation server so that the presentation servercan determine what updates the client device did not receive andtherefore needs to be sent.
 45. The presentation server of claim 1 whichis sent by the client device any parameters that need to be persistentand stores these parameters or routes them to storage for laterretrieval.
 46. The presentation server of claim 1 which providesscalability in the number of client devices a network based applicationcan communicate with by being itself scalable with: (a) multiple CPUs ona machine; (b) multiple CPUs on multiple machines in a parallel or in aparent/child arrangement, and managing the message flows from each CPUto the applicable client devices.
 47. The presentation server of claim 1which provides fault tolerance by being itself scalable with: (a)multiple CPUs on a machine; (b) multiple CPUs on multiple machines in aparallel or in a parent/child arrangement, providing a mechanism toautomatically compensate for failures of instances on one or more CPUsby reconfiguring the network configuration at run-time and optionallyre-establish connectivity for each orphaned client device to analternate presentation server
 48. The presentation server of claim 1,forming part of a network of several geographically separatedpresentation servers, some or all of which operate as edge servers. 49.The presentation server of claim 1 forming part of a network of severalgeographically separated machines organised into a topology which isappropriate to the physical arrangement of sites in a business runningthe network based application.
 50. The presentation server of claim 1which can combine structured data from several different server basedapplications for a given client device.
 51. The presentation server ofclaim 1 which can determine automatically and in real time, when aclient device requests several images, whether it should reducebandwidth consumption by placing all of the images into a single,composite image file, each image sharing data which is not imagespecific.
 52. The presentation server of claim 1 which modifies the datait sends to a client in dependence on information sent to it from theclient which relates to the display limitations of the client device.53. The presentation server of claim 1 which uses a session objectassociated with an applet to determine the specific display parametersand structured data to be served to the client device.
 54. Thepresentation server of claim 1 in which the data source is a web server,a back end application or a web service.
 55. A web application which,when invoked or run, causes a presentation server defined in anypreceding claims 1-54 to be run.
 56. A hardware server, which hosts apresentation server defined in any preceding claims 1-54.